ME>Доступ к ф-циям примитивов синхронизации обычно является вызовом ф-ции, например EnterCriticalSection(). После вызова ф-ции компилятор не может делать никаких предположений о состоянии переменных, поэтому при следующем доступе переменная будет зачитана из памяти, независимо от volatile'ности. volatile ни достаточен, ни полезен.
Это понятно, компилятор ее перечитает. Но где гарантия того что она перечитается корректно в многопроцессорной
среде если ее до этого изменил другой процессор?
Ведь компилятор не вставит lock...
... << Rsdn@Home 1.1.4 beta 1 >>
Re[9]: boost::thread
От:
Аноним
Дата:
22.06.04 11:10
Оценка:
Здравствуйте, MaximE, Вы писали:
ME>maq wrote:
>>>> ME>P.S. В этом случае volatile не нужен. >>>> Почему? >> >> ME>Потому что volatile был придуман для регистров устройств и в C/C++ он не имеет никакого отношения к threading. >> ME>Подробности можешь разыскать на deja.com по ключевым словам "volatile terekhov". >> >> Тогда получается что нет способа гарантированно читать переменную в которую могут писать несколько потоков, >> даже если она защищена критичиской секцией?
ME>Доступ к ф-циям примитивов синхронизации обычно является вызовом ф-ции, например EnterCriticalSection(). После вызова ф-ции компилятор не может делать никаких предположений о состоянии переменных, поэтому при следующем доступе переменная будет зачитана из памяти, независимо от volatile'ности. volatile ни достаточен, ни полезен.
ME>Можно рассматривать volatile как антиоптимизацию в mutlithreaded programming. И как одно из самых распространенных заблуждений.
Опять чуть не забыл.
Стандарт C++. 1.9 Program execution
keywords: sequence points
side effects
Это к тому, что volatile нужен не часто.
Но в данном конкретном случае "кашу" он не испортит.
>>> Ну откуда такие сведения? Или это твое IMHO? >>> Тут ты не прав. lock не нужен. >>> См. Manual на IA32, IA64. > > ME>http://rsdn.ru/Forum/?mid=357586
> > ME>Особенно последний абзац цитаты. > > Ну процитируй его сюда. Мне тупому. > Читаю и не нахожу грабель. > > Пожалуйста, процитируй, что тебе не нравится,
Accesses to cacheable memory that are split across bus widths, cache lines and page boundaries are not guaranteed to be atomic by the Pentium 4, Intel Xeon, P6 family, Pentium and Intel486 processors. The 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.
> а рядом тут же попытайся перевести.
...Accesses to cacheable memory that are split across bus widths, cache lines... — у каждого проца своя cache line
...bus control signals that permit external memory subsystems to make split accesses atomic... — это префикс lock
On a multiprocessor (which C does not recognize), "sequence points" can only
be reasonably interpreted to refer to the view of memory from that
particular processor. (Otherwise the abstract model becomes too expensive
to be useful.) Therefore, volatile may say nothing at all about the
interaction between two threads running in parallel on a multiprocessor.
On a high-performance modern SMP system, memory transactions are effectively
pipelined. A memory barrier does not "flush to memory", but rather inserts
barriers against reordering of operations in the memory pipeline. For this
to have any meaning across processors there must be a critical sequence on
EACH end of a transaction that's protected by appropriate memory barriers. This protocol has no possible meaning for an isolated volatile variable,
and therefore cannot be applied.
The protocol can only be employed to protect the relationship between two
items; e.g., "if I assert this flag then this data has been written" paired
with "if I can see the flag is asserted, then I know the data is valid".
That's how a mutex works. The mutex is a "flag" with builtin barriers
designed to enforce the visibility (and exclusion) contract with data
manipulations that occur while holding the mutex. Making the data volatile
contributes nothing to this protocol, but inhibits possibly valuable
compiler optimizations within the code that holds the mutex, reducing
program efficiency to no (positive) end.
If you have a way to generate inline barriers (or on a machine that doesn't
require barriers), and you wish to build your own low-level protocol that
doesn't rely on synchronization (e.g., a mutex), then your compiler might
require that you use volatile -- but this is unspecified by either ANSI C
or POSIX. (That is, ANSI C doesn't recognize parallelism and therefore
doesn't apply, while POSIX applies no specific additional semantics to
"volatile".) So IF you need volatile, your code is inherently nonportable.
A corollary is that if you wish to write portable code, you have no need for
volatile. (Or at least, if you think you do have a need, it won't help you
any.)
plads_project
> ME>На x86 атомарность чтения байта, слова, двойнога слова гарантируется только на однопроцессорной машине. На многопроцессорной придется использовать префикс lock, чего без asm'a не сделать. > > Если ты под чтением и записью подразумевал команду mov, то гарантируется и на многопроцессорной тоже.
На многопроцессорной не гарантируется. См. цитату из intel reference.
> И вообще, lock перед mov дает при выполнении исключение invalid lock sequence.
> Я прокомментировал заблуждение относительно атомарности. > volatile же к атомарности действительно никакого отношения не имеет.
Over quoting — из того, что ты выше процитировал, трудно сделать вывод, что ты писал не про volatile.
-- Maxim Yegorushkin
Posted via RSDN NNTP Server 1.9 beta
Re[9]: boost::thread
От:
Аноним
Дата:
22.06.04 12:09
Оценка:
Здравствуйте, MaximE, Вы писали:
>>>> Ну откуда такие сведения? Или это твое IMHO? >>>> Тут ты не прав. lock не нужен. >>>> См. Manual на IA32, IA64. >> >> ME>http://rsdn.ru/Forum/?mid=357586
>> >> ME>Особенно последний абзац цитаты. >> >> Ну процитируй его сюда. Мне тупому. >> Читаю и не нахожу грабель. >> >> Пожалуйста, процитируй, что тебе не нравится,
ME>
ME>Accesses to cacheable memory that are split across bus widths, cache lines and page boundaries are not guaranteed to be atomic by the Pentium 4, Intel Xeon, P6 family, Pentium and Intel486 processors. The 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.
>> а рядом тут же попытайся перевести.
ME>...Accesses to cacheable memory that are split across bus widths, cache lines... — у каждого проца своя cache line
Во блин. Перевод. Литературный нафиг.
Здесь that are инициирует перечисления состоящее из 3х пунктов.
"Доступы к закешированной памяти, которая разделена(пересекает): ширину шины, строки кэша и границы страниц --- не является атомарным by ...".
Тепрь ответь? 1 байт может превысить разрядность шины, строк кэша, или
пересечь границы страниц?
ME>...bus control signals that permit external memory subsystems to make split accesses atomic... — это префикс lock
Ну, ты же в общем-то правильные выводы сделал.
to make split accesses atomic --- чтобы доступ к не выровненным данным сделать
атомарным.
Ты в принципе-то понимаешь или нет, что говорить вообще о том, что переменная
1 байт может быть выровнена или не выровнена бессмысленно?
1 байт не может пересечь ширину шины данных, строку кэша, границы страниц.
1 байт --- это наименьшая и неделимая единица адресация за всю историю x86.
[skipped...] Ну загрузил. Это я тебе переведу чуть по позже.
Пока времени особо нет. Да и вообще давай пока апеллировать к официальной
документации.
>> ME>На x86 атомарность чтения байта, слова, двойнога слова гарантируется только на однопроцессорной машине. На многопроцессорной придется использовать префикс lock, чего без asm'a не сделать. >> >> Если ты под чтением и записью подразумевал команду mov, то гарантируется и на многопроцессорной тоже.
ME>На многопроцессорной не гарантируется.
И как же ты представляешь себе неатомарность в данном случае?
ME>См. цитату из intel reference.
Да даже если будет у каждого процессора по три кеша . Не влияет это на атомарность или неатомарность операций.
Если считаешь, что тут я что-то упускаю из вида, то поясни.
>> И вообще, lock перед mov дает при выполнении исключение invalid lock sequence.
ME>А где ты в обсуждении увидел mov?
Вероятно, ты не заметил мои слова "Если ты под чтением и записью подразумевал команду mov"
Accesses to cacheable memory that are split across bus widths
Как я понимаю, типичным Access такого рода является инструкция add [mem],...
Она должна сачала прочитать ячейку памяти, потом произвести сложение, а потом её записать. Между чтением и записью другой процессор действительно может что-то натворить .
Но вспомни с чего началась эта ветка. Человек предложил использовать переменную nbDoCalc. В том случае требуются только чтение и запись.
Re[9]: boost::thread
От:
Аноним
Дата:
22.06.04 12:33
Оценка:
Здравствуйте, plads_project, Вы писали:
ME>>>См. цитату из intel reference.
_>По поводу этой цитаты еще вот что могу добавить: _>
_>Accesses to cacheable memory that are split across bus widths
_>Как я понимаю, типичным Access такого рода является инструкция add [mem],... _>Она должна сачала прочитать ячейку памяти, потом произвести сложение, а потом её
записать. Между чтением и записью другой процессор действительно может что-то натворить .
Пожалуй твой перевод вернее.
_>Но вспомни с чего началась эта ветка. Человек предложил использовать переменную nbDoCalc. В том случае требуются только чтение и запись.
Будет все Ok. У нас 1 писатель и 1 читатель.
Даже если я заменю mov nbDoCalc,0 на
sub nbDoCalc, 1
> ME>...Accesses to cacheable memory that are split across bus widths, cache lines... — у каждого проца своя cache line > > Во блин. Перевод. Литературный нафиг. > Здесь that are инициирует перечисления состоящее из 3х пунктов. > > > "Доступы к закешированной памяти, которая разделена(пересекает): ширину шины, строки кэша и границы страниц --- не является атомарным by ...". > > Тепрь ответь? 1 байт может превысить разрядность шины, строк кэша, или > пересечь границы страниц?
Ключевое место — split across ... cache lines. Т.е. один и тот же участок памяти или часть его находится в разных cache lines (даже не разных кэшах, что значит это относится и к одному процессору, о чем и сказано). byte по определенному адресу может легко находится в более чем одной cache line, dword может даже находится частично (скажем, low word) в одном cache line, частично (high word) в другом.
[]
> Ты в принципе-то понимаешь или нет, что говорить вообще о том, что переменная > 1 байт может быть выровнена или не выровнена бессмысленно? > 1 байт не может пересечь ширину шины данных, строку кэша, границы страниц. > > 1 байт --- это наименьшая и неделимая единица адресация за всю историю x86.
Я говорю не про байт, а про кэширование, см. выше.
plads_project wrote:
>>> ME>На x86 атомарность чтения байта, слова, двойнога слова гарантируется только на однопроцессорной машине. На многопроцессорной придется использовать префикс lock, чего без asm'a не сделать. >>> >>> Если ты под чтением и записью подразумевал команду mov, то гарантируется и на многопроцессорной тоже. > > ME>На многопроцессорной не гарантируется. > > И как же ты представляешь себе неатомарность в данном случае?
Я никак представляю, т.к. не являюсь специалистом по архитектуре процессоров intel вообще, и по их кэшам в частности. Я доверяю reference от intel.
Здравствуйте, MaximE, Вы писали:
>> ME>...Accesses to cacheable memory that are split across bus widths, cache lines... — у каждого проца своя cache line >> >> Во блин. Перевод. Литературный нафиг. >> Здесь that are инициирует перечисления состоящее из 3х пунктов. >> >> >> "Доступы к закешированной памяти, которая разделена(пересекает): ширину шины, строки кэша и границы страниц --- не является атомарным by ...". >> >> Тепрь ответь? 1 байт может превысить разрядность шины, строк кэша, или >> пересечь границы страниц?
ME>Ключевое место — split across ... cache lines. Т.е. один и тот же участок памяти или часть его находится в разных ME>cache lines (даже не разных кэшах, что значит это относится и к одному процессору, о чем и сказано). byte по ME>определенному адресу может легко находится в более чем одной cache line, dword может даже находится частично
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
вот это опять твое IMHO. ME>(скажем, low word) в одном cache line, частично (high word) в другом.
Я вообще перестаю тебя понимать.
Объясни мне как может часть 1 го байта "находиться в разных cache lines"?
Положим ты прав и дурной процессор заводит несколько копий одного и того
же байта в нескольких cache lines. Тут понимаешь начинаются такие проблемы
даже в однопоточных приложениях. Что ой мама.
Не надо додумывать ничего. В manuale все конкретно и понятно сказано.
Здравствуйте, plads_project, Вы писали:
А>>Все равно будет все Ok без lock. _>Хотя я бы все-таки использовал какой-нибудь объект синхронизации
А я и не настаиваю.
В конечно счете юзеру, наблюдающему progress bar
глубоко по барабану используете ли вы
объекты синхронизации, треды и другую хрень.
>>> Я подчеркиваю. Для синхронизации в данном конкретном случае >>> не нужно использвовать примитивы синхронизации из boost::thread. >>> Это по overhead. Достаточно использовать общую переменную >>> размерностью 1(!) BYTE(!). >>> При этом Вы не потеряете в нисколько в переносимости кода. > > ME>Потеряете. Без ассемблера не обойтись. > > ME>На x86 атомарность чтения байта, слова, двойнога слова гарантируется только на однопроцессорной машине. На многопроцессорной придется использовать префикс lock, чего без asm'a не сделать.
> Ну откуда такие сведения? Или это твое IMHO? > Тут ты не прав. lock не нужен. > См. Manual на IA32, IA64.
Да, действительно я был не прав.
Чтение и запись байта, выровненных word, double word, quad word гарантировано атомарны. Атомарность операций read-modify-write, для которых и предназначен префикс lock, не гарантируется (есть исключения).
Здравствуйте, Tom, Вы писали:
K>>WBR, Alexei K.
Tom>ну тогда уже во первых Tom>volatile BYTE nbDoCalc = 1;
Читай внимательно. Я еще позавчера 21.06.04 об этом
упоминал с подачи maq.
Tom>а во вторых если уж используется буст и thread, то писать надо Tom>мультиплатформный код....
Интересно, а на какой платформе этот код не
будет работать и почему?
Сразу уточню: IA32, IA64 работает.
И вообще с логико-теоритической точки зрения
на этой платформе вообще возможно будет
писать мультитредовый код?
. Не влияет это на атомарность или неатомарность операций.
