|
7 / 7 / 4
Регистрация: 07.07.2011
Сообщений: 583
|
||||||
lock в условие или в цикле09.12.2019, 08:48. Показов 5505. Ответов 72
Здравствуйте. Как известно одна переменная в разных потоках требует блокировки, иначе результат изменения переменной будет не предсказуемый. Но если в одном потоке переменная (например) bool меняется, а во втором только проверяется, то обязательно ли блокировать изменение переменной или это лишнее? Если bool меняется асинхронно в обоих потоках, то да-надо. Но если меняется только в одном, а во втором просто проверяется или в if() или в while, то зачем что то блокировать?
0
|
||||||
| 09.12.2019, 08:48 | |
|
Ответы с готовыми решениями:
72
Acer aspire 5552G-N974G64Mikk Проблема с Caps Lock, Num Lock, Scroll Lock
Клавиатура мигает всеми тремя индикаторами Caps Lock, Scroll Lock и Num Lock и соответственно не работает! |
|
Модератор
|
|||||
| 09.01.2022, 15:10 | |||||
|
Как минимум для этого должна быть ссылка на кеш. Как может быть одна ссылка быть оптимальнее другой? А с учётом динамического выделения памяти, сбора мусора и т.п. с кешем только проблем добавится для дополнительной синхронизации. Фактически, там где-то в глубинах .Net, какое-то кеширование происходит, так как физическая адресация объекты в памяти не постоянна (можно зафиксировать, но это не относится к теме вопроса). Но уровне Шарпа от нас всё это инкапсулировано и на этом уровне никакого кеширования ссылок нет. В реальных приложения 99.99% разработчиков никогда за свою карьеру с таким не столкнутся. То есть знать это нужно, на случай проявления каких-то непонятных багов. Но вот заранее учитывать в каждом приложении это вряд ли нужно. Изменение Name - это запись одного машинного слова. Производится за полтакта процессора. Добавлено через 3 минуты И использовать для синхронизации внешних операций экземпляр NameClass или любой другой локер - не имеет никакой разницы. Конечно, можно придумать массу сценариев в которой изменение какой-то переменой вызывает какую-то логику и на время её работы другие потоки не должны работать со старым значением. Но к изменению самого свойства в NameClass это не имеет отношения.
1
|
|||||
|
17823 / 12973 / 3382
Регистрация: 17.09.2011
Сообщений: 21,261
|
||
| 09.01.2022, 15:13 | ||
|
Если класс документируется как потокобезопасный, то вся синхронизация производится как часть его реализации, если нет, то внутри синхронизировать ничего не нужно и это должен делать внешний код, использующий класс в многопоточном сценарии — см. List<T> и пр.
0
|
||
|
Модератор
|
|||||||
| 09.01.2022, 15:20 | |||||||
|
Выше я дал две реализации NameClass. В каком сценарии может первая работать неправильно, а вторая (с локерами в свойстве) правильно? Допустим если есть событие об изменении, то имеет смысл локировать геттер
0
|
|||||||
|
109 / 52 / 16
Регистрация: 09.06.2021
Сообщений: 480
|
||||
| 09.01.2022, 15:24 | ||||
|
0
|
||||
|
Модератор
|
||||
| 09.01.2022, 15:35 | ||||
|
Этим занимается, наверное, даже не компилятор Шарпа, а виртуальная машина CLR уже при запуске CIL. Допустим, в объекте несколько зависимых свойств. Вам надо их прочитать и произвести какие-то действия. Сам объект хранится в локальной переменной, но для чтения его свойств вам приходится обращаться уже к вложенным переменным несколькими командами. И если в это время другой поток начнёт изменять свойства объекта, то вы может получить при чтении часть старых и часть новых значений свойств. В таких сценариях следует реализовывать локированные транзакции для чтения и записи все свойств скопом. Добавлено через 2 минуты Добавлено через 1 минуту А string - это ссылочный иммутабельный тип. Создаётся новая строка и уже после этого свойству Name будет присвоена просто ссылка на эту строку. Присвоение ссылки - это уже атомарная операция.
0
|
||||
|
109 / 52 / 16
Регистрация: 09.06.2021
Сообщений: 480
|
||||
| 09.01.2022, 15:40 | ||||
|
Добавлено через 2 минуты
0
|
||||
|
Модератор
|
|||||
| 09.01.2022, 15:46 | |||||
|
И lock в этом не помощник. За безопасность на таком уровне отвечает CLR. А для decimal два или четыре (зависит от архитектуры процессора). Добавлено через 43 секунды Добавлено через 2 минуты В зависимости от архитектуры процессора это может быть оно машинное слово, а может быть и два. Поэтому, в общем случае, изменение операции с long не атомарны. Но в архитектуре x-64 - атомарны.
0
|
|||||
|
109 / 52 / 16
Регистрация: 09.06.2021
Сообщений: 480
|
|||
| 09.01.2022, 15:48 | |||
|
0
|
|||
|
Модератор
|
||||||||
| 09.01.2022, 16:02 | ||||||||
|
Прочитайте. Или так и будете за каждый тип отдельно интересоваться? На уровня Шарпа такого кеширования просто нет. Локирование bool (в упаковке) или другого атомарного типа нужно в том случае, когда его изменение взывает какую-то зависимую логику, на время работы которой это значение должно быть неизменным. Простейший пример:
0
|
||||||||
|
109 / 52 / 16
Регистрация: 09.06.2021
Сообщений: 480
|
|||||
| 09.01.2022, 16:18 | |||||
|
0
|
|||||
|
Модератор
|
||
| 09.01.2022, 16:37 | ||
|
И к работе с регистрами это не имеет ни какого отношения. Там есть логика зависимая от флагов и речь идёт об учитывании этой логики. Кроме этого при создании .Net типов стараются учесть самые невероятные и редкие сценарии. Допустим, как писал kolorotur, вы можете писать приложение для 8-битового контролера, отменить вырывание в памяти и т.д. В этих случаях даже int и short уже нельзя будет считать атомарными. Но часто вы пишите на Шарпе многопоточные приложения для 8-битовых контролеров? Добавлено через 11 минут Fylhtq05, гарантированная атомарность на всех платформах обеспечивает только класс Interlocked Class.
0
|
||
|
109 / 52 / 16
Регистрация: 09.06.2021
Сообщений: 480
|
||||
| 09.01.2022, 16:41 | ||||
|
0
|
||||
|
Модератор
|
|||
| 09.01.2022, 16:56 | |||
|
Для Плюсов создаётся машинный код, а для Шарпа CIL. И, теоретически, один и тот же CIL может исполняться на любой архитектуре, в том числе и там где, вообще, не предусмотрено никаких регистров. Работая на Шарпе вы не работаете с реальной памятью, регистрами т .п. Те же ссылки хранящиеся в переменных могут быть изменены при перераспределении физической памяти. И ответственность за эту синхронизацию несёт уже CLR, а не Шарп. У вас может быть ссылка на один объекте в десятках разных переменных. И в какой-то момент CLR начнёт менять эти ссылки, но менять она их будет так, что для Шарпа все эти переменные всегда, в любой момент времени указывают на один и тот же объект. Без разницы где он находится в памяти, в регистре, или в кеше на диске. Добавлено через 6 минут Но объяснил, что одного флага иногда для этого мало. Нужна ещё некая инфраструктура для правильной работы с таким флагам. И речь шла о том, следует ли её каждый раз реализовывать самому или использовать уже имеющийся тип с такой логикой. В простых случаях (>90% приложений), простой флаг без проблем можно использовать вместо токена отмена. Единственный случай где невозможно без него реализовать - это отмена созданной, но не запущенной задачи. Заменить нельзя, поскольку это является частью реализации тасков.
0
|
|||
|
109 / 52 / 16
Регистрация: 09.06.2021
Сообщений: 480
|
|
| 09.01.2022, 17:06 | |
|
0
|
|
|
Модератор
|
||
| 09.01.2022, 17:31 | ||
|
Это разная оптимизация кода. И к потокобезопасности это не имеет никакого отношения. В том числе никакое локирование не поможет это решить.
0
|
||
|
109 / 52 / 16
Регистрация: 09.06.2021
Сообщений: 480
|
||
| 09.01.2022, 17:36 | ||
|
Он прав, что причиной является кеширование bool?
0
|
||
|
Модератор
|
|||||||||||||||||
| 09.01.2022, 18:16 | |||||||||||||||||
|
Это временное запоминание значение в какой-то быстро доступной памяти для ускорения работы с ней. Я думаю, здесь проблема не в этом, а то в том, что по разному компилируется при разных оптимизациях. Пример:
1
|
|||||||||||||||||
|
109 / 52 / 16
Регистрация: 09.06.2021
Сообщений: 480
|
|||||||
| 09.01.2022, 20:03 | |||||||
0
|
|||||||
|
Модератор
|
|||||||
| 09.01.2022, 20:22 | |||||||
|
Fylhtq05, в данном случае достаточно вставить
Фактически для внешних переменных используемых в lock он как бы добавляет volatile в их объявление. Добавлено через 2 минуты То есть проблема именно не в кешировании как таковом, а то что при разных оптимизациях создаётся разный CIL код. Локальное считывание внешних переменных всегда есть в CIL. А вот логика повторного внешнего считывания при некоторых оптимизациях компилятором опускается. Добавлено через 4 минуты Оптимизация порой создаёт такие проблемы. Ведь компилятор не может залезть в голову разработчика и узнать как он ожидает работу кода. Поэтому приходится либо отказываться от оптимизации, либо как-то изменять код чтобы компилятор "понял мысли" разработчика. Добавлено через 2 минуты kolorotur, volatile достаточно для решения подобной проблемы или есть сценарии где это не поможет?
1
|
|||||||
|
109 / 52 / 16
Регистрация: 09.06.2021
Сообщений: 480
|
||||
| 09.01.2022, 20:24 | ||||
|
И все же, то как ведет себя релиз это соответствует документации? Или вы считаете что лочить bool вообще-то не надо?
0
|
||||
| 09.01.2022, 20:24 | |
|
Работа с клавиатурой (клавиши num lock, caps lock, scroll lock) Оптимизирует ли компилятор выражения в цикле типа 90*M_PI или каждую итерацию в цикле считает заново? Горят лампочки caps lock и num lock, ноутбук не включается Условие в цикле
Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |
|
Новые блоги и статьи
|
|||
|
сукцессия 29. Переход от одних деревьев на другие делать более или менее вероятностным?
anaschu 12.07.2026
Насколько смена типов микоризы — исключительное событие в двухвековой сукцессии? Оценка вероятности в пространстве параметров
В текущей версии модели успешно реализован ключевой механизм. . .
|
сукцессия 27. Думаю, как переделывать уже написанную статью с планами на сукцессию.
anaschu 12.07.2026
Анализ соответствия модели требованиям
Реализованные компоненты:
Механизм закисления почвы через протонную помпу
Конкуренция между типами микориз
pH как триггер сукцессии
C/ P соотношение. . .
|
Сукцессия 26. Мат модель создана.
anaschu 12.07.2026
Модель смены растительных сукцессий посредством управления грибами работает внутри небольшой ячейки почвы, восстанавливающейся после пожара, где ненадолго бывшее царство хвойных снова захватили. . .
|
Решил проблему с ошибкой пагинации сообщений с сервера на алгоритме обхода дерева "Эстафета хвоста".
Hrethgir 12.07.2026
Проблема была в том, что удалялась именно новая кнопка, а не старая. Ни один ИИ не обнаружил это, а сам я смог только когда с работой стало попроще и когда заставил работать будущее автономное. . .
|
|
сукцессия 25. Хронология ошибок
anaschu 12.07.2026
# От 50-тонного гриба до устойчивого леса: хроника ошибок при построении модели вековой сукцессии микоризы
## О чём эта статья
В процессе построения ОДУ-модели (система дифференциальных. . .
|
сукцессия 24. Промежуточное общее описание модели
anaschu 12.07.2026
Хендофф: модель АМ→ЭКМ сукцессии микоризы (ризосфера, 50 лет)
Содержание проекта
Симуляция вековой (50 лет) экологической сукцессии в почве леса
Основные участники: АМ-гриб, ЭКМ-гриб,. . .
|
сукцессия 23. Более физиологичная физиология, более экологичная экология, более диффурные диффуры.
anaschu 12.07.2026
Что реально нашли и починили за эти 5 часов
Правило Линдемана (КПД конверсии сахара в тело, kEff) — раньше 100% полученного углерода шло прямо в биомассу гриба; теперь только kEff=0. 5 (после. . .
|
сукцессия 22. От артефактов к физиологии: калибровка агентной модели грибной сукцессии для воспроизведения сезонной динамики и pH-плато
anaschu 11.07.2026
Аннотация
В данной работе представлена калибровка агентной модели динамики грибных сообществ (fungal-succession), направленная на устранение нефизичных артефактов (коллапс биомассы, мгновенное. . .
|