Синхронизация

← →
Кто б сомневался © (2010-10-07 03:12) [0]

Забыл.
Если один поток меняет integer, а другой читает его. Вроде для этого не нужна синхронизация (в данном случае крит. секция)? Нужна она только для пишущих потоков. Кто бы напомнил?

← →
Юрий Зотов © (2010-10-07 03:18) [1]

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

← →
antonn © (2010-10-07 03:20) [2]

Доступ к объекту из разных потоков - синхронизация. Если смотреть на integer как на "объект" и делать синхронизацию не задумываясь как оно ляжет в памяти и можно ли читать напрямую, то проблем не будет. Делай "обвязку" на все, не парь себе мозг :)

← →
DiamondShark © (2010-10-07 11:31) [3]

> Если один поток меняет integer, а другой читает его.

То InterlockedXXX им в руки.
Как минимум.

> Вроде для этого не нужна синхронизация (в данном случае
> крит. секция)?

Тут смотри, какое дело.
Просто изменённый интегер он ведь сам по себе редко кому особо нужен.
Гораздо чаще этот смый интегер чего-то такое обозначает: флаги какие-то, код состояния чего-то и т.п.
Так вот в этом случае доступ (и на запись, и на чтение!) к этому интегеру должен быть быть синхронизирован ВМЕСТЕ с блоком кода, который меняет то состояние объектов, которое отражает этот самый интегер.

← →
DVM © (2010-10-07 12:02) [4]

Лучше использовать синхронизацию всегда и спать спокойно.

← →
Кто б сомневался © (2010-10-07 17:13) [5]

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

Изменения будут читать по таймеру. Раз в 300 мс. Пропуски - неважно.
Ок, если 200 потоков (для примера) читают одну переменную integer, а 201 поток ее изменяет - и все это без крит. секции - что может произойти? Ничего не произойдет по идее.

> Лучше использовать синхронизацию всегда и спать спокойно.
>
>

Да я просто не хочу чтобы потоки часто засыпали (с случае с КС). Это ж ресурсы все таки.

← →
Кто б сомневался © (2010-10-07 17:17) [6]

> Ок, если 200 потоков (для примера) читают одну переменную
> integer, а 201 поток ее изменяет - и все это без крит. секции
> - что может произойти? Ничего не произойдет по идее.

Может ли произойти теоретически AV? Почему? Просто интересно.

← →
Empleado © (2010-10-07 17:17) [7]

"То InterlockedXXX им в руки"

← →
Кто б сомневался © (2010-10-07 17:21) [8]

> Empleado © (07.10.10 17:17) [7]
>
> "То InterlockedXXX им в руки"

Да я в курсе. integer это для примера.

← →
DVM © (2010-10-07 17:27) [9]

> Может ли произойти теоретически AV?

не может

> Ничего не произойдет по идее.

цитата из книги Глубины Indy:

15.2.2. Атомарные операции (Atomic Operations)
Методология утверждает, что атомарные операции не требуют защиты. Атомарные операции – это такие операции, которые очень малы для деления в процессоре. Поскольку, их размер маленький, то это не приводит к спорам, так как они выполняются разом и не могут быть прерваны во время исполнения. Обычно атомарные операции – это строки кода компилируемые в одну иструкцию ассемблера.
Обычно задачи, такие как чтение или запись целых чисел (integer) или логических полей (boolean field) являются атомарными операциями, так как они выполняются с помощью единственной инструкции move. Тем не менее моя рекомендация, такая – никогда не рассчитывайте на атомарность операций, поскольку в некоторых случаях, даже при записи целого (integer) или логического (Boolean) может быть выполнено более одной инструкции, в зависимости от того, откуда данные читались. В дополнение, это требует знания внутренней природы компилятора, которое является предметом для изменения в любое время, без вашего оповещения. Закладываясь на атомарные операции вы можете написать код, который будет неоднозначным в некоторых случаях и может работать по разному на многопроцессорных машинах или других операционных системах.
Я до недавнего времени считал атомарные операции очень защищенными. Тем не менее, приход .NET принесет серьезную проблему. Когда наш код был компилирован в IL, и затем перекомпилирован в машинный код на платформах различных производителей, можете ли вы быть уверены, что каждая строка вашего кода будет атомарной операцией в конце концов?
Выбор конечно ваш, и конечно есть аргументы как за, так и против атомарных операций. Атомарные операции в большинстве случаев сохраняют только несколько микросекунд и несколько байт кода. Я настоятельно рекомендую не использовать атомарные операции, так как они дают мало преимуществ и являются потенциальным источником неприятностей.

> Ок, если 200 потоков (для примера) читают одну переменную
> integer, а 201 поток ее изменяет - и все это без крит. секции
> - что может произойти?

Используй класс со страшным названием TMultiReadExclusiveWriteSynchronizer

← →
DiamondShark © (2010-10-07 17:48) [10]

> Изменения будут читать по таймеру. Раз в 300 мс. Пропуски
> - неважно.Ок, если 200 потоков (для примера) читают одну
> переменную integer, а 201 поток ее изменяет - и все это
> без крит. секции - что может произойти? Ничего не произойдет
> по идее.

Это архитектурный бред.
Если 200 потоков интересует изменение переменной, то они должны дрыхнуть. А изменяющий поток сигнализировать об изменении посылкой сообщения или установкой объекта синхронизации (ивента, например).

← →
Кто б сомневался © (2010-10-07 17:50) [11]

Спасибо.
Вызвало недоумение лишь одна строка:

>чтение или запись целых чисел (integer) или логических полей (boolean field) являются >атомарными операциями
> Я настоятельно рекомендую не использовать атомарные операции

← →
Кто б сомневался © (2010-10-07 17:54) [12]

> DiamondShark © (07.10.10 17:48) [10]

Не вырывай фразы из контекста.
Читать по таймеру - это одно, а 200 потоков, это совершенно другое - это теоретический пример для вопроса. С чего ты взял что 200 потоков должны опрашивать по таймеру? Написано же в скобках "для примера".

← →
DiamondShark © (2010-10-07 17:58) [13]

> Написано же в скобках "для примера".

Ну я и говорю: бредовый пример.

А зачем читать по таймеру? Читать надо по факту изменения. А для сигнализации изменения -- либо посылать сообщение, либо PulseEvent.

← →
Юрий Зотов © (2010-10-07 18:07) [14]

Хлопцы, теория - это хорошо, но спуститесь на землю грешную. В конкретной задаче, о которой идет речь, атомарность/неатомарность не играют никакой роли.

> Кто б сомневался © (07.10.10 17:13) [5]
Исключений не возникнет. Но что именно прочитает каждый из 200 потоков - это вопрос. Может получиться так, что часть из них прочитают "позавчерашнее" значение, часть - "вчерашнее", а еще часть - "сегодняшнее".

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

Но грамотное решение - [10].

← →
Кто б сомневался © (2010-10-07 18:07) [15]

> А зачем читать по таймеру? Читать надо по факту изменения.
> А для сигнализации изменения -- либо посылать сообщение,
> либо PulseEvent.

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

← →
Кто б сомневался © (2010-10-07 18:08) [16]

> Synchronizе - что в моем случае усложняет и путает код.

Плюс к тому же это довольно "тяжелый" метод.

← →
Кто б сомневался © (2010-10-07 18:20) [17]

Опрос по таймеру - вещь удобная, и главное без усложнения кода. Плюс отладка очень простая и низкая вероятность ошибок.
Есть ядро оно что-то делает. Есть GUI который когда ему удобно читает данные. Все. "Никакой" связи между ними нет. Подобную структуру я уже довольно давно использую.

← →
DiamondShark © (2010-10-07 18:33) [18]

> Есть GUI который когда ему удобно читает данные.

Гую сам Атеос велел читать данные по сообщению.

← →
Кто б сомневался © (2010-10-07 18:44) [19]

> Гую сам Атеос велел читать данные по сообщению.

Читать по сообщению (message) вариант хороший - но зависит от задачи.
Если изменений будет много, то и сообщений будет много - думаю это не есть хорошо.
А если делать без опроса, т.е. отображать из других потоков, то придется делать Synchronizе.
Таймер пока лучший вариант.

← →
DiamondShark © (2010-10-07 18:58) [20]

> Читать по сообщению (message) вариант хороший - но зависит
> от задачи.

Нисколько не зависит.

> Если изменений будет много, то и сообщений будет много -
> думаю это не есть хорошо.

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

> Таймер пока лучший вариант.

Таймер, на секундочку, работает именно по сообщениям. Так что таймер -- это кривая эмуляция чтения по сообщению.

← →
Юрий Зотов © (2010-10-07 19:00) [21]

> > Есть GUI который когда ему удобно читает данные.

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

← →
Кто б сомневался © (2010-10-07 19:04) [22]

> Таймер, на секундочку, работает именно по сообщениям. Так
> что таймер -- это кривая эмуляция чтения по сообщению.

Таймер срабатывает через определенный интервал, причем здесь принцип его работы. Сообщения могут приходить аж через пол секунды.
Таймер 300 это наиболее экономичный плане ресурсов вариант.
Synchronizе самый медленный. Messages - между ними и то в зависимости от задачи.

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

Если частота сообщений будет слишком частая, есть вероятность что GUI начнет тормозить в разных проявлениях.

← →
Игорь Шевченко © (2010-10-07 19:17) [23]

Зачем Борис (MBo) мучился, книгу переводил, а А.П. из нее PDF делал и у себя на сайте размещал - напрочь непонятно. Делать людям нефиг.

← →
DiamondShark © (2010-10-07 19:21) [24]

> Таймер срабатывает через определенный интервал, причем здесь
> принцип его работы.

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

> Таймер 300 это наиболее экономичный плане ресурсов вариант.

Если события происходят реже, чем 1/300, то это излишне затратный вариант.
Если события происходят чаще, чем 1/300, то теряются значимые события.

> Synchronizе самый медленный.

Точно такой же, как сообщения. Только дельфизависимый.

> Messages - между ними и то в зависимости от задачи.

Ровно столько, сколько нужно, ни меньше, ни больше.

> Если частота сообщений будет слишком частая, есть вероятность
> что GUI начнет тормозить в разных проявлениях.

Для этого надо очень сильно постараться, во-первых.
Во-вторых, если уж у тебя поток событий такой, что способен забить очередь сообщений, то твой таймер 300 из входящего потока выберет чуть менее, чем нифига. Зато, да, тормозить не будет.

Мы говорим о сферических конях в вакууме, или у тебя какой-то реальный поток событий есть?

← →
Кто б сомневался © (2010-10-07 19:45) [25]

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

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

← →
Кто б сомневался © (2010-10-07 19:47) [26]

> > Synchronizе самый медленный.
>
> Точно такой же, как сообщения. Только дельфизависимый.

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

← →
DVM © (2010-10-07 20:53) [27]

> Кто б сомневался © (07.10.10 17:50) [11]
> Спасибо.
> Вызвало недоумение лишь одна строка:
>
> >чтение или запись целых чисел (integer) или логических
> полей (boolean field) являются >атомарными операциями
> > Я настоятельно рекомендую не использовать атомарные операции
>
>

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

← →
Eraser © (2010-10-07 20:59) [28]

Обновлять GUI по таймеру это хорошо. Но защищать обязательно нужно крит. секцией. Как писал дядя Рихтер, не нужно боятся использовать крит. секции )

← →
miek (2010-10-07 22:04) [29]

Чисто для справки.
И чтение и запись _выровненного_ одного 4-байтного слова (не побайтное) в любой системе на архитектуре IA-32 всегда будет атомарной операцией. Не нужны никакие средства синхронизации, все всегда будет когерентно.

www.intel.com/Assets/PDF/manual/253668.pdf

оттудова:

7.1.1 Guaranteed Atomic Operations The Intel486 processor (and newer processors since) guarantees that the following basic memory operations will always be carried out atomically: • Reading or writing a byte • Reading or writing a word aligned on a 16-bit boundary • Reading or writing a doubleword aligned on a 32-bit boundary The Pentium processor (and newer processors since) guarantees that the following additional memory operations will always be carried out atomically: • Reading or writing a quadword aligned on a 64-bit boundary • 16-bit accesses to uncached memory locations that fit within a 32-bit data bus The P6 family processors (and newer processors since) guarantee that the following additional memory operation will always be carried out atomically: • Unaligned 16-, 32-, and 64-bit accesses to cached memory that fit within a cache line Accesses to cacheable memory that are split across bus widths, cache lines, and page boundaries are not guaranteed to be atomic by the Intel Core 2 Duo, Intel Core Duo, Pentium M, Pentium 4, Intel Xeon, P6 family, Pentium, and Intel486 processors. The Intel Core 2 Duo, Intel Core Duo, Pentium M, Pentium 4, Intel Xeon, and P6 family processors provide bus control signals that permit external memory subsystems to make split accesses atomic; however, nonaligned data accesses will seriously impact the performance of the processor and should be avoided.

> DVM © (07.10.10 22:18) [30]

Тут люди теоретизируют (фантазируют я бы даже сказал) про разные ОС и процессоры. Типа "вообще всегда", а не только про интел :)

Впрочем, про выровненность и .NET, например - верно замечено, как оно реально расположит - фик знает.

по-моему вернее всего подмечено в [3].

> по-моему вернее всего подмечено в [3].

Если точно известно что будет только один поток изменять данные, зачем городить огород?Уже известно что за универсальностью лучше не гнаться - получиться хуже.

← →
Дмитрий Тимохов (2010-10-08 16:46) [34]

я бы синхронизировал, хотя работать будет корректно и без синхронизации.

и не мучал моск

> Кто б сомневался © (08.10.10 15:21) [33]

Так потоки читают целое значение с какой целью? От этого зависит - нужна синхронизация или нет.

> DVM © (07.10.10 12:02) [4]
> Лучше использовать синхронизацию всегда и спать спокойно.

Это другая крайность и тоже неправильная. Если везде использовать синхронизацию, то:
1) рискуешь нарваться на deadlock. А потенциально deadlock уже возможен, если есть вложенные критические секции и их порядок при разных путях исполнения может быть разный.
2) деградирует производительность из-за возникающих bottleneck и накладных расходов на синхронизацию.

Так что всё нужно делать в меру.

← →
Fr0sT (2010-10-26 10:43) [37]

Имхо, критическая секция - идеальный вариант, намного менее затратный, чем Synchronize.
Остальные варианты зависят от задачи и набора данных, который пересылается гую.
У меня есть проект с кучей сокетов во вспомогательном потоке, при изменении состояния или приёме очередного пакета я создаю в памяти структуру состояния и отправляю указатель на неё через PostMessage в главную форму. По-моему, отличный способ.

Извращение.

Кстати, никто не подскажет, как красиво за"Interlock"ить свойство Boolean, есть ли способ?
TMyClass = .... .................. FBooleanValueInt: integer; function GetBooleanValue: boolean; procedure SetBooleanValue(const Value: boolean); public property BooleanValue: boolean read GetBooleanValue write SetBooleanValue; end; function TMyClass.GetBooleanValue: boolean; begin Result := Boolean(FBooleanValueInt) end; procedure TMyClass.SetBooleanValue(const Value: boolean); begin InterlockedExchange(FBooleanValueInt, Integer(Value)) end;

но для симметрии не хватает Interlock"а при чтении, в GetBooleanValue. Возможно?

Синхронизация Найти похожие ветки