lock в условие или в цикле

@nnnikotinnn995 · Регистрация: 07.07.2011

Студворк — интернет-сервис помощи студентам

Здравствуйте. Как известно одна переменная в разных потоках требует блокировки, иначе результат изменения переменной будет не предсказуемый. Но если в одном потоке переменная (например) bool меняется, а во втором только проверяется, то обязательно ли блокировать изменение переменной или это лишнее? Если bool меняется асинхронно в обоих потоках, то да-надо. Но если меняется только в одном, а во втором просто проверяется или в if() или в while, то зачем что то блокировать?

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
bool ExitFromGame=false;
private Thread myThreadnN1, myThreadnN2;
static void Main(string[] args){
myThreadnN1 = new Thread(Exit);myThreadnN1.Start();
myThreadnN2= new Thread(Listen); myThreadnN2.Start();
}
private void Listen() {
                while(!ExitFromGame) {//как это блокировать и надо ли?
                }
}
public void Exit() {
         Thread.Sleep(1000);ExitFromGame=true;//надо ли писать lock(this){ExitFromGame=true;} ?
        }

@Элд Хасп · 09.01.2022, 20:35

Сообщение от Fylhtq05

И все же, то как ведет себя релиз это соответствует документации? Или вы считаете что лочить bool вообще-то не надо?

Дело не Release, а в компиляторе.
Каждый компилятор может по своему оптимизировать код и даже один и тот же компилятор можно настраивать по разному.
Вы можете в Студии залезть в настройки Release (правда не помню куда именно) и изменить применяемую в этом режиме оптимизацию.

Но вопрос в этой теме другой.
Он о защите переменной при её изменении.
Допустим, если вы создадите поле decimal и будете его менять одновременно из множества потоков, то вы в какой-то моент можете получить в нём значение которого нет ни в одном из потоков.
Один поток запишет первые 8 байт, другой вторые 8 - и получится неизвестно что.
С int такого на x86 и x64 невозможно.
С long такое возможно на x86.
Вот именно это и является следствием атомарности или её отсутствия.

В реальных приложениях на такое можно напороться, хотя и очень редко.
И, конечно, в реале для обеспечения потокобезопасности всегда используют локировку.
Не сколько из-за этих нюансов, сколько из-за того что обычно надо обеспечивать потокобезопасность не только одной команды/операторы, а какой-то их группы.

@Элд Хасп · 09.01.2022, 20:39

Сообщение от Fylhtq05

Я проверил код с lock, он работает в отличие от кода без lock:

Для подтверждения, что лок здесь не причём в моём коде достаточно вставить пустой лок в тело цикла.
И всё заработает как надо:

C#
15
16
17
18
19
20
21
22
23
24
25
        private int PrivateStart()
        {
            int sum = 0;
            while (!Flag)
            {
                sum++;
                lock (this) { }
            }
 
            return sum;
        }

@Fylhtq05 · 09.01.2022, 20:44

Сообщение от Элд Хасп

Дело не Release, а в компиляторе.

Сообщение от Элд Хасп

Для подтверждения, что лок здесь не причём в моём коде достаточно вставить пустой лок в тело цикла.

Компилятор лагает или все в соответствии с документацией на Шарп?

@Элд Хасп · 09.01.2022, 21:04

Сообщение от Fylhtq05

Компилятор лагает или все в соответствии с документацией на Шарп?

Это не относится к спеку Шарпа (как я думаю).
По спеку код компилируется так чтобы его логика не нарушалась в однопоточном исполнении.
Для гарантировано правильной работы в многопотоке все нюансы этого разработчик должен учитывать самостоятельно.

@Fylhtq05 · 09.01.2022, 21:13

Элд Хасп, ни чего не понял.

Сообщение от Элд Хасп

Это не относится к спеку Шарпа (как я думаю).

В смысле? Если компилятор делает что-то не предусмотренное спеком, значит он лагает. Или не так?

Сообщение от Элд Хасп

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

Не понял. А если приложение многопоточное компилятор может делать все что хочет, вне зависимости от написанного кода? Т.е. написал в соответствии с руководством многопоточный код, а компилятор за его выполнение не отвечает?

Сообщение от Элд Хасп

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

Так вопрос в том, как это учитывать, если даже в таком простом случае пока непонятно, компилятор лагает или такой код и должен выполняться так?

@Элд Хасп · 09.01.2022, 22:07

Сообщение от Fylhtq05

В смысле? Если компилятор делает что-то не предусмотренное спеком, значит он лагает. Или не так?

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

Допустим, возвращаясь к предыдущему примеру, есть код метода:

C#
1
2
3
4
5
6
7
8
9
        public int Start()
        {
            int sum = 0;
            while (!Flag)
            {
                sum++;
            }
            return sum;
        }

Как следует его оптимизировать?
Ведь никаких указаний на то, что здесь будет использована многопоточность нет.
Надо предположить, что возможно она кому-то приспичит и метод оптимизировать под многопоточность, но при этом для однопотока он не будет оптимальным?

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

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

Добавлено через 13 минут

Сообщение от Fylhtq05

Т.е. написал в соответствии с руководством многопоточный код, а компилятор за его выполнение не отвечает?

Как по коду метода понять, что это многопоточный код?
Компилятор это не волшебная палочка.
Он компилирует код в меру того насколько может его понять.

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

Сообщение от Fylhtq05

Так вопрос в том, как это учитывать, если даже в таком простом случае пока непонятно, компилятор лагает или такой код и должен выполняться так?

Это не простой случай, а именно один из тех которые находятся "в сумеречной области".
Кроме самого спека есть ещё различные рекомендации по реализации тех или иных задач.
Они появились не на пустом месте.
И если разработчики .Net (то есть MS) дают какую-то рекомендацию, то следует её исполнять.

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

@Fylhtq05 · 09.01.2022, 22:24

Сообщение от Элд Хасп

Как по коду метода понять, что это многопоточный код?

Конечно, по маленькому участку кода, который заключен в метод, нельзя понять, что bool изменяется в другом месте программы. Значит или не надо оптимизировать до такой степени, чтобы логика кода не работала или смотреть нет ли возможности изменения переменной в других частях программы. Но это же не оправдание, что компилятор с каким-то участком кода может делать все что захочет, вне зависимости от того, что происходит за этим участком.

Сообщение от Элд Хасп

Это не простой случай, а именно один из тех которые находятся "в сумеречной области".

Тоже мне теорема Геделя. "Сумеречные области" указаны в спеках?

Сообщение от Элд Хасп

И если разработчики .Net (то есть MS) дают какую-то рекомендацию, то следует её исполнять.

Рекомендация, по самому смыслу этого слова, это не обязанность и не запрет на что-то. Т.е. если что-то рекомендовано, можно не делать, но тогда либо код будет большой, либо производительность падает, потому лучше прислушаться. Но криминала в том не следовали рекомендациям не должно быть. А если они есть, то надо называть это не рекомендациями, а требованиями спека. Потому, если есть в спеках, что делать так нельзя, то компилятор лагает.

@Элд Хасп · 09.01.2022, 22:34

Сообщение от Fylhtq05

Но это же не оправдание, что компилятор с каким-то участком кода может делать все что захочет, вне зависимости от того, что происходит за этим участком.

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

Сообщение от Fylhtq05

"Сумеречные области" указаны в спеках?

Всё что прямо не указанно в спеке, относится к ним.

Сообщение от Fylhtq05

Рекомендация, по самому смыслу этого слова, это не обязанность и не запрет на что-то.

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

@Fylhtq05 · 09.01.2022, 22:51

Сообщение от Элд Хасп

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

Это новое определение общепринятого слова "рекомендация". Обычно это = советовать. И советы может каждый давать. У нас даже раньше целая страна была страной советов.

Сообщение от Элд Хасп

Всё что прямо не указанно в спеке, относится к ним.

В спеках написано, что if исполняется, если bool == true. В спеках написано, что переменную bool можно изменять. В спеках описан каждый оператор. Все что описано в спеках применено. Но код работает не по спекам. Значит...

@Элд Хасп · 09.01.2022, 23:38

Fylhtq05, у меня нет цели изменить спек, компилятор или переубедить вас.
Я вам только объясняю как всё устроено, и на мой взгляд это довольно логично.
Какого-то предмета спора я здесь не вижу.
Вот так вот оно устроено.
Если вы считаете это нелогичным, то вы можете написать свои правки и отправить их разработчикам.
Или забить на это и принять логику разработчиков.

@Fylhtq05 · 10.01.2022, 11:47

Сообщение от Элд Хасп

Я вам только объясняю как всё устроено

Я именно про устройство и пишу. Все предельно ясно. Все операторы описаны в спеках. В чем вы видите "сумеречные области"?

Сообщение от Элд Хасп

вы можете написать свои правки и отправить их разработчикам

Я об этом не спрашивал.

@Элд Хасп · 10.01.2022, 12:43

Сообщение от Fylhtq05

Все операторы описаны в спеках. В чем вы видите "сумеречные области"?

Где описано взаимодействие данных из разных потоков?

Там где нужна синхронизация значений между потоками в документации написано:

volatile (Справочник по C#)
Ключевое слово volatile означает, что поле может изменить несколько потоков, выполняемых одновременно. Компилятор, среда выполнения или даже аппаратное обеспечение могут изменять порядок операций чтения и записи в расположения в памяти для повышения производительности. Поля, которые объявлены volatile, исключаются из некоторых типов оптимизации. Нет никакой гарантии единого общего прядка временных записей во всех потоках выполнения. Дополнительные сведения см. в описании класса Volatile.

Примечание

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

Я же вам показал разный CIL для разных оптимизаций.
По объёму кода он отличается в полтора раза.
По скорости возможно даже больше.
Прокидывание изменений между потоками это дорогое удовольствие.
И в >99% методах это не нужно.
Стоит ли специально замедлять все методы чтобы получить "выигрыш" в очень редких задачах?

@Fylhtq05 · 10.01.2022, 13:17

Сообщение от Элд Хасп

вы можете написать свои правки и отправить их разработчикам

Что я это могу я знаю.

Сообщение от Элд Хасп

Где описано взаимодействие данных из разных потоков?

Именно это я спрашивал. kolorotur показал код, работу которого в релизе объяснял кешированием. Вы сказали, что кеширование тут не причем и объяснили это сумеречной областью. Теперь пояснили, что имели в виду.
Про volatile я писал lock в условие или в цикле
kolorotur говорит, что volatile проблему не решит, еще раз привожу цитату:

Сообщение от kolorotur

volatile отключает оптимизации по перемещению инструкций чтения/записи относительно друг друга для этой переменной.
Т.е. отключает ровно один тип оптимизации из многих, производимых рантаймом и компилятором.

Вы говорите решит. Если решит, то я прав в теме В чем смысл проверки IsCancellationRequested в циклах?

@Элд Хасп · 10.01.2022, 13:42

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

Добавлено через 12 минут

Сообщение от Fylhtq05

Именно это я спрашивал. kolorotur показал код,

Вы смешали вопросы двух тем, да еще кроме топика тем добавили дополнительные вопросы.
Изначально в этой теме никакой речи о кешировании между потоками не шло.
Речь шла об обязательности лакирования переменных простого типа для того чтобы обеспечить её предсказуемое значение.

В рамках этого вопроса и были мои ответы.

Потом вы подняли вопрос о кешировании, что опять таки в рамках этого вопроса не имеет значения.

Потом уже подтянули вопросы из своей второй темы, и добавили к ним дополнительные.
В результате всё это переросло уже в синхронизацию переменной изменяемой в разных потоках.

Может в вашем представления это всё одно и тоже.
Но в моём это, хоть и где-то связанные темы, но все же это разные темы.
И даже одни и те же термины в них означают разные понятия.

Допустим, вы упоминали кеширование в регистрах.
Это кеширование не имеет никакого отношения к "кешированию" из-за отсутствия синхронизации между потоками.
Во втором случае, это даже кешированием назвать можно только условно.

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

Если вопрос изменить на:

Нужно ли для синхронизации переменной простого типа между потоками её локировать?

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

@Элд Хасп · 10.01.2022, 13:50

Сообщение от Fylhtq05

Если решит, то я прав в теме В чем смысл проверки IsCancellationRequested в циклах?

Это решит во многих реальных случаях.

Образно.
В 99% задач это, вообще, не нужно.
Из оставшегося 1% в 99% случаев этого будет достаточно.
Но остаётся ещё 0.01% задач в которых нужна более тщательная реализация этих моментов.

Не забывайте, что Шарп задумывался как многоплатформенный инструмент, он должен работать и в системе на одном 8-битовом процессоре и в каком-то сервере с тысячами процессоров.
И то что какой-то подход будет работать конкретно на вашем компе (условно) не значит, что это будет работать на всех других возможных конфигурациях.
А в отношении многопоточности это воще жуть.
Она даже на физическом уровне на разных платформах реализована очень по разному.

@kolorotur · 10.01.2022, 14:10

Сообщение от Элд Хасп

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

Это именно гарантия — читайте спек про критические точки, порядок выполнения и наблюдаемые эффекты.
Если вкратце, то блок lock создает такую критическую точку, в которой наблюдаемые эффекты должны быть синхронизированы по времени, т.е. если какой-то другой поток изменил некий участок памяти, в блоке lock эти изменения обязаны быть наблюдаемыми.

@Fylhtq05 · 10.01.2022, 14:15

Сообщение от Элд Хасп

Вы смешали вопросы двух тем, да еще кроме топика тем добавили дополнительные вопросы.

Я не имел права на вопрос из другой темы, но относящийся к этой? Или не имел права на "дополнительные вопросы"? Поясните, тогда я постараюсь исправиться.

Сообщение от Элд Хасп

Изначально в этой теме никакой речи о кешировании между потоками не шло.

Изначально вопрос темы:

Сообщение от nnnikotinnn995

Но если в одном потоке переменная (например) bool меняется, а во втором только проверяется, то обязательно ли блокировать изменение переменной или это лишнее?

kolorotur в другой теме считает, что обязательно при этом надо учитывать кеширование. Я не имел права приводить другие источники для выяснения вопроса?

Сообщение от Элд Хасп

Речь шла об обязательности лакирования переменных простого типа для того чтобы обеспечить её предсказуемое значение.

И я о том же. О предсказуемости.

Сообщение от Элд Хасп

Может в вашем представления это всё одно и тоже.
Но в моём это, хоть и где-то связанные темы, но все же это разные темы.

В моем представлении это связанные темы настолько, чтобы не создавать новую. Но c вашим мнением, как модератора, спорить не буду.
А на заданный в последнем топике вопрос можете поподробнее ответить?

@Элд Хасп · 10.01.2022, 14:21

Сообщение от kolorotur

Это именно гарантия — читайте спек про критические точки, порядок выполнения и наблюдаемые эффекты.

Не читал.
Не могли бы дать ссылку - беглый поиск не дал результатов.

Сообщение от kolorotur

в блоке lock эти изменения обязаны быть наблюдаемыми.

В том числе это объясняет синхронизацию при использовании пустого lock?

@Элд Хасп · 10.01.2022, 14:23

Сообщение от Fylhtq05

Я не имел права на вопрос из другой темы, но относящийся к этой? Или не имел права на "дополнительные вопросы"? Поясните, тогда я постараюсь исправиться.

Вопрос не втом что имели или нет.
А в том, что я отвечал на одни вопросы, а вы эти ответы "натягиваете" на другие вопросы.
Я же не телепат и не могу знать из какой-темы появились ваши вопрос и в каком контексте они заданы.

@kolorotur · 10.01.2022, 14:44

Элд Хасп, в принципе, раздел 3.10 неплохо все суммирует:

3.10 Execution order

Execution of a C# program proceeds such that the side effects of each executing thread are preserved at critical execution points. A side effect is defined as a read or write of a volatile field, a write to a non-volatile variable, a write to an external resource, and the throwing of an exception. The critical execution points at which the order of these side effects must be preserved are references to volatile fields (§‎10.5.3), lock statements (§‎8.12), and thread creation and termination. The execution environment is free to change the order of execution of a C# program, subject to the following constraints:

Data dependence is preserved within a thread of execution. That is, the value of each variable is computed as if all statements in the thread were executed in original program order.
Initialization ordering rules are preserved (§‎10.5.4 and §‎10.5.5).
The ordering of side effects is preserved with respect to volatile reads and writes (§‎10.5.3).
Additionally, the execution environment need not evaluate part of an expression if it can deduce that that expression’s value is not used and that no needed side effects are produced (including any caused by calling a method or accessing a volatile field). When program execution is interrupted by an asynchronous event (such as an exception thrown by another thread), it is not guaranteed that the observable side effects are visible in the original program order.

Новые блоги и статьи Все статьи Все блоги /
После бана на Пикабу не работает авторизация аккаунта с Яндекса. Hrethgir 09.07.2026 В частности https:/ / auto. ru/ logbook/ zapret-na-vozhdenie-posle-65-let_1cf28789-07b4-4c75-a2f7-4cd4edf9deeb тут хотел оставить комментарий такой Зрите в корень - монополизация на разработку программ. . .	GitDOS: Когда я решил скрестить MS-DOS, GitHub и Claude MaGz GoLd 08.07.2026 Привет, Киберфорум! Хочу поделиться своим проектом, который, надеюсь, вас заинтересует. GitDOS — это веб-приложение, которое позволяет запускать DOS в браузере с тремя крутыми фичами: диски живут в. . .	Учебный мини "цифровой двойник" = (Сервер = Java + Flask_питон )+(3D = Гугловскаая 4T nvideo + google colab) +( WMS = Odoo на Docker) anaschu 07.07.2026 Увидел в требованиях к вакансии создателя имитационных моделей связку (REst + Api + WMS + Anylogic + питон + 3D Nvideo), и решил посмотреть, что это такое. Из этого всего я работал более менее. . .	Море в объективе kumehtar 06.07.2026 Хотел написать много проникновенных слов, но передумал. Оно само - говорит. Кто слышит тот слышит.
Doom для терминала без стрельбы и монстров. 3D Raycasting на ascii. dcc0 05.07.2026 Попросил нейронную сеть deepai. org написать рейкастинг 3D с библиотекой ncurses для Linux. Чтобы можно было ходить на стрелочки. Чтобы стены были отрисованы символами. Справилась. Первый вариант. . .	Установка статуса документа по условию Maks 05.07.2026 Алгоритм из решения ниже реализован на нетиповом документе "НарядПутевка" разработанного в КА2. Задача: в табличной части "Материалы" документа при записи автоматически устанавливать статус. . .	Сезонность и суточность закисления почв anaschu 04.07.2026 200 часов это все равно моловато. Есть ситуации, но нестандартные, когда смена происходит за 5 лет. Но обычно это 50 лет и более. Наверное, закисление почвы происходит сезонно в средней. . .	В чем ценность человеческого опыта в глобальном смысле? kumehtar 03.07.2026 Возможно, ценность человека не в том, что он однажды достигает мудрости, а в том, что он становится носителем карты пути. Он знает не только истину, но и последовательность внутренних изменений,. . .

@Элд Хасп Модератор 16154 / 11275 / 2890 Регистрация: 21.04.2018 Сообщений: 33,153 Записей в блоге: 2
	09.01.2022, 23:38
	Fylhtq05, у меня нет цели изменить спек, компилятор или переубедить вас. Я вам только объясняю как всё устроено, и на мой взгляд это довольно логично. Какого-то предмета спора я здесь не вижу. Вот так вот оно устроено. Если вы считаете это нелогичным, то вы можете написать свои правки и отправить их разработчикам. Или забить на это и принять логику разработчиков. 0