Есть локальная переменная bool-типа, которую изменяет один поток а читает другой. Какие могут быть проблемы?

Пример:

class Program
    {
        static void Main(string[] args)
        {
            bool b = true;

            new Thread(() =>
            {
                Thread.Sleep(5000);
                b = false;
            }) {IsBackground = true}.Start();

            while (b)
            {
                Console.WriteLine("b=" + b);
                Thread.Sleep(1000);
            }

            Console.WriteLine("b=" + b);
        }
    }

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

S>Есть локальная переменная bool-типа, которую изменяет один поток а читает другой. Какие могут быть проблемы?
Если переменная не volatile и нет лока вокруг, то чтение, вероятно, может быть соптимизировано и читающий поток не получит нового значения.

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

S>Есть локальная переменная bool-типа, которую изменяет один поток а читает другой. Какие могут быть проблемы?

Большие.

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

S>Есть локальная переменная bool-типа, которую изменяет один поток а читает другой. Какие могут быть проблемы?

Могут быть проблемы, если будет код типа:

if (a != boolValue) // boolValue - та самая общая переменная
{
  a = boolValue; // к этому моменту уже значение boolValue может быть изменено другим потоком
{

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

S>Есть локальная переменная bool-типа, которую изменяет один поток а читает другой. Какие могут быть проблемы?

Проблем быть не должно.
У каждого потока будет свой экземпляр этой переменной.

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

V>Если переменная не volatile и нет лока вокруг, то чтение, вероятно, может быть соптимизировано и читающий поток не получит нового значения.

Локальная не может быть volatile.

Добавил пример — попробуйте продемонстрировать случай, когда возникает проблема.

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

S>>Есть локальная переменная bool-типа, которую изменяет один поток а читает другой. Какие могут быть проблемы?

Pzz>Большие.

Добавил пример — продемонстрируйте проблему.

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

K>Могут быть проблемы, если будет код типа:
K>

K>if (a != boolValue) // boolValue - та самая общая переменная
K>{
K>  a = boolValue; // к этому моменту уже значение boolValue может быть изменено другим потоком
K>{
K>

K>дальше можно еще нафантазировать.
K>А иногда можно взять CancellationToken и не делать свой велосипед на булевом флаге для отмены операции, если для этого такая переменная нужна.

Дык... По условиям — только один потом может изменить значение. Второй только читает.

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

M>Проблем быть не должно.
M>У каждого потока будет свой экземпляр этой переменной.

Если бы у каждого свой экземпляр — то второй поток не узнал бы, что первый изменил переменную. См. поясняющий пример.

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

V>>Если переменная не volatile и нет лока вокруг, то чтение, вероятно, может быть соптимизировано и читающий поток не получит нового значения.
S>Локальная не может быть volatile.
S>Добавил пример — попробуйте продемонстрировать случай, когда возникает проблема.
В этом примере после компиляции переменная уже не будет локальной, это будет член класса, который сгенерируется из захваченной переменной.
В релизной компиляции всё будет зависеть от настроек компиляции и внутренней логики оптимизатора.
При компиляции наружного чтения переменной компилятор может и не догадаться, что переменная другого класса может меняться.
Пытаться демонстрировать случай я не буду, но я бы не стал рисковать, делая такую синхронизацию потоков.

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

S>Дык... По условиям — только один потом может изменить значение. Второй только читает.

Ну, второй и прочитал два раза и два раза получил разное значение.
К чему это приведёт — зависит от программы

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

S>Локальная не может быть volatile.

Осталось разобраться как она так шарится между потоками

S>Добавил пример — попробуйте продемонстрировать случай, когда возникает проблема.

Для этого нужно знать как в итоге собираются лямбды.
Рекомендую скопировать код, например, в https://sharplab.io

M>>Проблем быть не должно.
M>>У каждого потока будет свой экземпляр этой переменной.
S>См. поясняющий пример.

Это не локальная переменная относительно функций потоков.

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

S>Добавил пример — продемонстрируйте проблему.

Вплоть до переупорядочивания чтений/записей процессором (не компилятором, а именно процессором).

В твоем простом примере, конечно, такое вряд ли поймаешь — пока Sleep() отработает, все 100500 раз устаканится. Но в реальной жизни они будут, причем проявляться будут весьма неочевидным и невоспроизводимым образом.

S>Добавил пример — попробуйте продемонстрировать случай, когда возникает проблема.

Например тут:

    public static int Main()
    {
        bool b = true;

        new Thread(() =>
        {
            Thread.Sleep(5);
            b = false;
        }) {IsBackground = true}.Start();

        while (b)
        {
            Console.WriteLine("b=" + b);
            Thread.Sleep(1);
        }

        Console.WriteLine("b=" + b);
        return 0;
    }

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

M>Например тут:

И что за проблему вы увидели?

M>>Например тут:

S>И что за проблему вы увидели?

Запусти несколько раз и увидишь как меняется вывод программы от запуска к запуску.

Здравствуйте, 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>Пытаться демонстрировать случай я не буду, но я бы не стал рисковать, делая такую синхронизацию потоков.

А причем тут синхронизация?

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

K>Ну, второй и прочитал два раза и два раза получил разное значение.
K>К чему это приведёт — зависит от программы

Разное значение — т.к. второй поток изменил. Что странного?