Если почти всегда требуется синхронизация потоков (т. Е. Использование мьютексов, семафоров, критических разделов и т. Д.), Когда есть доступ к сквозным потокам, даже если это не требуется после прохождения анализ требований?Рекомендации: синхронизация между потоками
Я бы всегда рекомендовал простейшую и простую схему синхронизации до тех пор, пока анализ не покажет, что вы должны сделать иначе - это обычно означает несколько больших замков по сравнению с многими мелкозернистыми замками или без блокировки.
Проблема в том, что определение правильности кода без блокировки намного сложнее, чем определение правильности соответствующего кода с замками. Это создает большую нагрузку на сопровождающих вашего кода, и есть хорошие шансы, что они ошибаются и вводят ошибки. Даже если вы знаете, что без блокировки безопасно использовать ваш код в настоящее время, это может измениться в будущем людьми, которые не так осведомлены.
Во-вторых, во многих случаях разница в производительности между кодом с блокировками и кодом без блокировки является пренебрежимым - пока вы не знаете, что есть проблема с конфликтом блокировки, вы не должны рассматривать блокировку. Даже если есть проблемы с конфликтом, блокировка не обязательно является лучшим решением.
Спасибо за ваше объяснение. Я полагаю, что использование блокировки было бы лучшей практикой для будущих целей использования исходного кода. – stanigator
Даже если вам не нужны мьютекс, семафор, критический раздел и т. Д. Для их нормальной семантики блокировки, вам все равно может понадобиться memory barrier. Первые конструкции обычно подразумевают барьер памяти, поэтому их удаление может изменить программу. Кроме того, эти проблемы могут быть чрезвычайно сложными для отладки, поскольку другое планирование задействованных потоков может заставить проблему исчезнуть и появиться. В простейшем случае это означает, что простой акт запуска полностью отдельной программы изменяет ваше поведение.
Другая модель, которая имеет смысл, называется share-nothing. erlang и scala, вероятно, являются главными представителями этой модели с процессами erlang и актерами scala.
Идея состоит в том, что вы отправляете сообщения в другие потоки, где сообщения - это данные, данные которых не отправляются отправителем. На практике существует небольшая блокировка, необходимая для очередей отправки/получения, но остальная часть кода может быть заблокирована без каких-либо проблем.
Такие модели могут быть реализованы на языках C++ и других языках.
http://www.scala-lang.org/node/242 http://lambda-the-ultimate.org/node/1742 http://docs.python.org/library/multiprocessing.html#module-multiprocessing
Если это не требуется, это не требуется. Что именно вы спрашиваете? – sth
Должен ли я блокировать потоки при доступе к данным через потоки независимо от того, требуется ли это или нет? – stanigator
Если это необходимо (чтобы избежать повреждения данных), сделайте это. Если это не требуется, не делайте этого ... –