Как лучше всего протестировать Взаимоисключающую реализацию?

Формальное доказательство лучше, чем тестирование такого рода вещей.

Тестирование покажет вам, что - если вам не повезло - все это сработало. Но испытание - инструмент тупой; он может не выполнить точную правильную последовательность, что приведет к сбою.

Слишком сложно протестировать каждую возможную последовательность операций, доступных на оборудовании, чтобы убедиться, что ваш мьютекс работает при любых обстоятельствах.

Испытания не лишены ценности; это показывает, что вы не допустили никаких очевидных ошибок кодирования.

Но вам действительно нужна более формальная проверка кода, чтобы продемонстрировать, что он делает правильные вещи в нужное время, чтобы один клиент атомарно захватил ресурс блокировки, необходимый для правильного мьютекса. На многих платформах есть специальные инструкции для реализации этого, и если вы используете одну из них, у вас есть шанс сделать это правильно.

Точно так же вы должны показать, что релиз является атомарным.

Я со всеми остальными, что это невероятно сложно доказать окончательно, я понятия не имею, как это сделать - я знаю, бесполезно!

Когда вы говорите о внедрении мьютекса, а повторное использование недопустимо, это связано с техническими причинами, например, отсутствием реализации Mutex на платформе / ОС, которую вы используете, или по какой-либо другой причине? Является ли упаковка некоторой формы «блокировки» уровня ОС и называть ее своей реализацией Mutex вариантом, например, CriticalSection на windoze, переменные условия posix? Если вы можете обернуть блокировку ОС более низкого уровня, то ваши шансы сделать это намного выше.

Если вы еще этого не сделали, прочтите статьи Herb Sutter's Effective Concurrency . В них должно быть что-то стоящее для вас.

В любом случае, некоторые моменты, которые следует учитывать в ваших тестах:

• Если ваш мьютекс является рекурсивным (то есть может один и тот же поток блокировать его несколько раз), убедитесь, что вы выполнили несколько тестов подсчета ссылок .
• С вашей глобальной переменной, которую вы изменяете, было бы лучше, если бы это была переменная , которую нельзя записать в атомарно. Например, если вы на 8-битной платформе, используйте 16- или 32-битную переменную, для которой требуется написать несколько инструкций сборки.
• Внимательно изучите список сборки. Хотя в зависимости от аппаратной платформы сборка не влияет напрямую на то, как код может быть оптимизирован ...
• Попросите кого-нибудь еще, кто не писал код, также написать несколько тестов.
• протестируйте на как можно большем количестве разных машин с разными спецификациями (при условии, что это «общее назначение», а не для конкретной конфигурации оборудования)

Удачи!

Используя нечто вроде мьютекса, мы возвращаемся к старому правилу, согласно которому тестирование может демонстрировать только наличие ошибок, а не их отсутствие. Год тестирования, вероятно, скажет вам меньше, чем просто выставить код на проверку и спросить, не видит ли кто-нибудь в нем проблемы.

Если доказательства этого не подтверждают? не работает для вас, тогда переходите к тестированию. Обязательно протестируйте все возможные варианты использования. Узнайте, как именно эта вещь будет использоваться, кто будет ее использовать и, опять же, как она будет использоваться. Когда вы идете по маршруту тестирования, обязательно запускайте каждый тест для каждого сценария множество раз (миллионы, миллиарды, столько, сколько вы можете получить за время тестирования, которое у вас есть).

Старайтесь быть случайным, потому что случайность даст вам лучший шанс охватить все сценарии в ограниченном количестве тестов. Обязательно используйте данные, которые будут использоваться, и данные, которые могут не использоваться, но могут быть использованы, и убедитесь, что данные не нарушают блокировки.

Кстати, если вы не разбираетесь в математике и формальных методах, у вас не будет никаких шансов найти доказательство.