Здравствуйте, Shmj, Вы писали:
S>Есть локальная переменная bool-типа, которую изменяет один поток а читает другой. Какие могут быть проблемы?
Если переменная не volatile и нет лока вокруг, то чтение, вероятно, может быть соптимизировано и читающий поток не получит нового значения.
Здравствуйте, Shmj, Вы писали:
S>Есть локальная переменная bool-типа, которую изменяет один поток а читает другой. Какие могут быть проблемы?
Могут быть проблемы, если будет код типа:
if (a != boolValue) // boolValue - та самая общая переменная
{
a = boolValue; // к этому моменту уже значение boolValue может быть изменено другим потоком
{
дальше можно еще нафантазировать.
А иногда можно взять CancellationToken и не делать свой велосипед на булевом флаге для отмены операции, если для этого такая переменная нужна.
Re: Доступ к локальной переменной из разных потоков
Здравствуйте, vmpire, Вы писали:
V>Если переменная не volatile и нет лока вокруг, то чтение, вероятно, может быть соптимизировано и читающий поток не получит нового значения.
Локальная не может быть volatile.
Добавил пример — попробуйте продемонстрировать случай, когда возникает проблема.
Re[2]: Доступ к локальной переменной из разных потоков
Здравствуйте, Pzz, Вы писали:
S>>Есть локальная переменная bool-типа, которую изменяет один поток а читает другой. Какие могут быть проблемы?
Pzz>Большие.
Добавил пример — продемонстрируйте проблему.
Re[2]: Доступ к локальной переменной из разных потоков
Здравствуйте, karbofos42, Вы писали:
K>Могут быть проблемы, если будет код типа: K>
K>if (a != boolValue) // boolValue - та самая общая переменная
K>{
K> a = boolValue; // к этому моменту уже значение boolValue может быть изменено другим потоком
K>{
K>
K>дальше можно еще нафантазировать. K>А иногда можно взять CancellationToken и не делать свой велосипед на булевом флаге для отмены операции, если для этого такая переменная нужна.
Дык... По условиям — только один потом может изменить значение. Второй только читает.
Re[2]: Доступ к локальной переменной из разных потоков
Здравствуйте, Shmj, Вы писали:
V>>Если переменная не volatile и нет лока вокруг, то чтение, вероятно, может быть соптимизировано и читающий поток не получит нового значения. S>Локальная не может быть volatile. S>Добавил пример — попробуйте продемонстрировать случай, когда возникает проблема.
В этом примере после компиляции переменная уже не будет локальной, это будет член класса, который сгенерируется из захваченной переменной.
В релизной компиляции всё будет зависеть от настроек компиляции и внутренней логики оптимизатора.
При компиляции наружного чтения переменной компилятор может и не догадаться, что переменная другого класса может меняться.
Пытаться демонстрировать случай я не буду, но я бы не стал рисковать, делая такую синхронизацию потоков.
Re[3]: Доступ к локальной переменной из разных потоков
Здравствуйте, Shmj, Вы писали:
S>Добавил пример — продемонстрируйте проблему.
Вплоть до переупорядочивания чтений/записей процессором (не компилятором, а именно процессором).
В твоем простом примере, конечно, такое вряд ли поймаешь — пока Sleep() отработает, все 100500 раз устаканится. Но в реальной жизни они будут, причем проявляться будут весьма неочевидным и невоспроизводимым образом.
Re[3]: Доступ к локальной переменной из разных потоков
Здравствуйте, Pzz, Вы писали:
Pzz>В твоем простом примере, конечно, такое вряд ли поймаешь — пока Sleep() отработает, все 100500 раз устаканится. Но в реальной жизни они будут, причем проявляться будут весьма неочевидным и невоспроизводимым образом.
На прошлой неделе аккурат это самое огрёб, из-за материализации linq-последовательности другим потоком, нежели тот который порождает
Упрощённо как-то так:
var b = init-bool-here();
var ohShit = data.Select(d => create-something-from-bool-val(b));
b = next-bool-logic();
Task.Run(() => foreach(var sh in ohShit) {...});
Когда оно так в три строчки нарисовано — всё сразу понятно, но в реальном коде это было куда более многословно. Когда увидел причину — поржал над собой
Здравствуйте, vmpire, Вы писали:
V>В этом примере после компиляции переменная уже не будет локальной, это будет член класса, который сгенерируется из захваченной переменной. V>В релизной компиляции всё будет зависеть от настроек компиляции и внутренней логики оптимизатора.
Попробуйте вспомнить, откуда вы об этому узнали. Просто по слухам или где-то в авторитетных источниках прочитали?
Много раз слышал, но теперь начинаю сомневаться — может просто кто-то сказал и все за ним начали повторять.
В реальности ни разу не удалось продемонстрировать проблему.
V>При компиляции наружного чтения переменной компилятор может и не догадаться, что переменная другого класса может меняться.
И что? Создаст свою копию переменной, так что второй поток на нее влиять не будет?
V>Пытаться демонстрировать случай я не буду, но я бы не стал рисковать, делая такую синхронизацию потоков.
А причем тут синхронизация?
Re[4]: Доступ к локальной переменной из разных потоков