Здравствуйте, What, Вы писали:

W>А зачем здесь синхронизация? Один поток пишет значение переменной, другой читает. Главное, чтобы значение было записано атомарно. Это в данном случае для x86 гарантируется.

Боюсь, что именно из-за таких предположений весь сыр бор вокруг volatile и начался. Я считаю, что есть принципиальные вещи: выделеную память нужно освобождать, открытые файлы закрывать, после входа в критическую секцию нужно выйти оттуда, ..., когда одна нить читает то, что другая может переписать, то это нужно синхронизировать. Это вопрос принципа (с моей точки зрения). И если ему следовать, то:
— мы не зависим от volatile или не volatile;
— мы не зависим от аппаратной платформы (могут быть какие-нибудь специализированные процессоры, на которых извлечение одного байта из памяти может не быть атомарной операцией, а требовать дополнительных арифметических операций/сдвигов);
— мы не зависим от типа данных. Сейчас у нас переменная go -- это bool. Завтра -- это long int, в котором указано, сколько итераций нам еще разрешают сделать. После завтра -- структура, в которой описывается, при каких условиях нужно выходить, а при каких условиях еще можно провести пару-тройку итераций.
А все из-за того, что изначально мы защитились синхронизацией. И не надеялись на особенности конкретной платформы и конткретного компилятора.

W>С другой стороны, а если бы рабочих потоков было, скажем, 4 вместо 1. И все читали бы одну и ту же переменную. Тогда использование синхронизации могло бы привести к ненужным потерям производительности.
За безопасность в многопоточности нужно платить. Некоторые из-за безопасности на более медленные языки программирования переходят Из-за того, что лишний раз delete вызвать лень

E>>Если бы вы использовали синхронизацию доступа к go, то volatile, наверняка, не потребовался бы.
W>Наверняка, да, не потребовался бы.

От тож!