Здравствуйте, ssm, Вы писали:
ssm>Здравствуйте, kzua, Вы писали:
K>>Вот уж CreateThread действительно нельзя писать.
K>>Только _beginthreadex !!!
ssm>почему?
Вообще-то:
Если тред использует только WIN32 API, и не
использует стандартные библиотеку C/C++, то
можно CreateThread.
Если используются стандартные библиотеки, то
нужно _beginthreadex.
Если используется MFC, то нужно AfxBeginThread
и нельзя _beginthreadex.
В общем об этом подробно написано в MSDN и
у Рихтера.
"Warning The multithread library LIBCMT.LIB includes the _beginthread and _endthread functions. The _beginthread function performs initialization without which many C run-time functions will fail. You must use _beginthread instead of CreateThread in C programs built with LIBCMT.LIB if you intend to call C run-time functions." (C) MSDN
Здравствуйте, maq, Вы писали:
maq>А может вы внимательнее прочитаете сообщение? maq>Человек спрашивает как сделать это в boost::thread...
Гы гы гы...
А че не так-то?
Ну положим пусть thread создает не с помощью _beginthreadex,
а boost::thread.
Я подчеркиваю. Для синхронизации в данном конкретном случае
не нужно использвовать примитивы синхронизации из boost::thread.
Это по overhead. Достаточно использовать общую переменную
размерностью 1(!) BYTE(!).
При этом Вы не потеряете в нисколько в переносимости кода.
K>Я подчеркиваю. Для синхронизации в данном конкретном случае K>не нужно использвовать примитивы синхронизации из boost::thread. K>Это по overhead. Достаточно использовать общую переменную K>размерностью 1(!) BYTE(!). K>При этом Вы не потеряете в нисколько в переносимости кода.
K>WBR, Alexei K.
Здравствуйте, maq, Вы писали:
K>>Я подчеркиваю. Для синхронизации в данном конкретном случае K>>не нужно использвовать примитивы синхронизации из boost::thread. K>>Это по overhead. Достаточно использовать общую переменную K>>размерностью 1(!) BYTE(!). K>>При этом Вы не потеряете в нисколько в переносимости кода.
maq> И даже не нужно объявлять ее как volatile?
Ох блин. Нужно нужно
Для полной нирваны да. Черт вылетело из головы.
Хе хе. Совсем забыл этот прикол:
while( nbDoJob )
{
...
};
kzua wrote:
> Я подчеркиваю. Для синхронизации в данном конкретном случае > не нужно использвовать примитивы синхронизации из boost::thread. > Это по overhead. Достаточно использовать общую переменную > размерностью 1(!) BYTE(!). > При этом Вы не потеряете в нисколько в переносимости кода.
Потеряете. Без ассемблера не обойтись.
На x86 атомарность чтения байта, слова, двойнога слова гарантируется только на однопроцессорной машине. На многопроцессорной придется использовать префикс lock, чего без asm'a не сделать.
>> ME>P.S. В этом случае volatile не нужен. >> Почему?
ME>Потому что volatile был придуман для регистров устройств и в C/C++ он не имеет никакого отношения к threading. ME>Подробности можешь разыскать на deja.com по ключевым словам "volatile terekhov".
Тогда получается что нет способа гарантированно читать переменную в которую могут писать несколько потоков,
даже если она защищена критичиской секцией?
Здравствуйте, MaximE, Вы писали:
ME>maq wrote:
>> ME>P.S. В этом случае volatile не нужен. >> >> Почему?
ME>Потому что volatile был придуман для регистров устройств и в C/C++ он не имеет никакого отношения к threading.
ME>Подробности можешь разыскать на deja.com по ключевым словам "volatile terekhov".
ME>-- ME>Maxim Yegorushkin
К треадингу он может и не имеет отношения, но вот это словцо говорит компилятору что бы он не сильно напрягал мозги по поводу оптимизации этой перменной. Или я не прав?
ME>Потеряете. Без ассемблера не обойтись.
ME>На x86 атомарность чтения байта, слова, двойнога слова гарантируется только на однопроцессорной машине. На многопроцессорной придется использовать префикс lock, чего без asm'a не сделать.
ME>P.S. В этом случае volatile не нужен.
Выдержка из IA-32 Intel® Architecture Software Developer’s Manual
7.1.1. Guaranteed Atomic Operations
The Pentium 4, Intel Xeon, P6 family, Pentium, and Intel486 processors guarantee 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 4, Intel Xeon, and P6 family, and Pentium processors guarantee 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 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 32-byte 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 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.
Re[5]: boost::thread
От:
Аноним
Дата:
22.06.04 09:20
Оценка:
Здравствуйте, MaximE, Вы писали:
ME>kzua wrote:
>> Я подчеркиваю. Для синхронизации в данном конкретном случае >> не нужно использвовать примитивы синхронизации из boost::thread. >> Это по overhead. Достаточно использовать общую переменную >> размерностью 1(!) BYTE(!). >> При этом Вы не потеряете в нисколько в переносимости кода.
ME>Потеряете. Без ассемблера не обойтись.
ME>На x86 атомарность чтения байта, слова, двойнога слова гарантируется только на однопроцессорной машине. На многопроцессорной придется использовать префикс lock, чего без asm'a не сделать.
ME>P.S. В этом случае volatile не нужен.
Ну откуда такие сведения? Или это твое IMHO?
Тут ты не прав. lock не нужен.
См. Manual на IA32, IA64.
Для 1 байта все в порядке.
lock нужен для переменных более 1го байта.
В случаях когда переменная не выровнена извлечение и запись
ее в ОП может происходить за несколько обращений к памяти.
Например: извлекли старший байт, затем извлекли младший байт.
поэтому чтобы никто из других процессоров не вклинился в
этот момент (к этому же участку памяти) используется блокировка шины на все время выполнения команды. lock.
lock ничего не делает кроме как монопольный захват шины на все время выполнения
команды (mov, inc и т.д.). Т.е. гарантирует атомарность.
Имея переменную размером 1 байт извлечение и запись ее будет производится атомарно.
Если какой-то CPU изменяет значение переменной, то он тут же скидывает ее в ОП
и сообщает остальным CPU об инвалидации данного участка памяти.
Поэтому они при следующем обращении возьмут значение переменной не из
cache, а из ОП.
Lock не запускает процедуру инвалидации. Lock лишь гарантирует атомарность!
Атомарность записи/чтения 1го байта гарантируется by design.
Так же гаранитруется атомарность записи/чтения выровненных переменных.
Все компиляторы генерят код с выравненными статическими переменными.
Поэтому приведенные код будет работать даже при WORD, DWORD разделяемой переменной.
new вроде тоже старается выдавать выравненные участки памяти
(хотя где гарантии?).
Наш пример самый элементарный: 1ый поток писатель, 2ой поток читатель.
Более элементарный пример придумать сложно (и есть ли вообще?).
Поэтому с 1 разделяемым байтом все будет в порядке.
Наворачивать сюда объекты синхронизации --- overhead.
>>> Я подчеркиваю. Для синхронизации в данном конкретном случае >>> не нужно использвовать примитивы синхронизации из boost::thread. >>> Это по overhead. Достаточно использовать общую переменную >>> размерностью 1(!) BYTE(!). >>> При этом Вы не потеряете в нисколько в переносимости кода. > > ME>Потеряете. Без ассемблера не обойтись. > > ME>На x86 атомарность чтения байта, слова, двойнога слова гарантируется только на однопроцессорной машине. На многопроцессорной придется использовать префикс lock, чего без asm'a не сделать. > > ME>P.S. В этом случае volatile не нужен. > > Ну откуда такие сведения? Или это твое IMHO? > Тут ты не прав. lock не нужен. > См. Manual на IA32, IA64.
maq wrote:
>>> ME>P.S. В этом случае volatile не нужен. >>> Почему? > > ME>Потому что volatile был придуман для регистров устройств и в C/C++ он не имеет никакого отношения к threading. > ME>Подробности можешь разыскать на deja.com по ключевым словам "volatile terekhov". > > Тогда получается что нет способа гарантированно читать переменную в которую могут писать несколько потоков, > даже если она защищена критичиской секцией?
Доступ к ф-циям примитивов синхронизации обычно является вызовом ф-ции, например EnterCriticalSection(). После вызова ф-ции компилятор не может делать никаких предположений о состоянии переменных, поэтому при следующем доступе переменная будет зачитана из памяти, независимо от volatile'ности. volatile ни достаточен, ни полезен.
Можно рассматривать volatile как антиоптимизацию в mutlithreaded programming. И как одно из самых распространенных заблуждений.
Здравствуйте, MaximE, Вы писали:
ME>На x86 атомарность чтения байта, слова, двойнога слова гарантируется только на однопроцессорной машине. На многопроцессорной придется использовать префикс lock, чего без asm'a не сделать.
Если ты под чтением и записью подразумевал команду mov, то гарантируется и на многопроцессорной тоже.
И вообще, lock перед mov дает при выполнении исключение invalid lock sequence.
Re[7]: boost::thread
От:
Аноним
Дата:
22.06.04 10:23
Оценка:
Здравствуйте, MaximE, Вы писали:
ME>bw wrote:
>> ME>P.S. В этом случае volatile не нужен. >> >> Выдержка из IA-32 Intel® Architecture Software Developer’s Manual
ME>[]
ME>К volatile это никакого отношения не имеет.
Я прокомментировал заблуждение относительно атомарности.
volatile же к атомарности действительно никакого отношения не имеет.
Re[7]: boost::thread
От:
Аноним
Дата:
22.06.04 10:29
Оценка:
Здравствуйте, MaximE, Вы писали:
>>>> Я подчеркиваю. Для синхронизации в данном конкретном случае >>>> не нужно использвовать примитивы синхронизации из boost::thread. >>>> Это по overhead. Достаточно использовать общую переменную >>>> размерностью 1(!) BYTE(!). >>>> При этом Вы не потеряете в нисколько в переносимости кода. >> >> ME>Потеряете. Без ассемблера не обойтись. >> >> ME>На x86 атомарность чтения байта, слова, двойнога слова гарантируется только на однопроцессорной машине. На многопроцессорной придется использовать префикс lock, чего без asm'a не сделать. >> >> ME>P.S. В этом случае volatile не нужен. >> >> Ну откуда такие сведения? Или это твое IMHO? >> Тут ты не прав. lock не нужен. >> См. Manual на IA32, IA64.
ME>http://rsdn.ru/Forum/?mid=357586
Ну процитируй его сюда. Мне тупому.
Читаю и не нахожу грабель.
Пожалуйста, процитируй, что тебе не нравится,
а рядом тут же попытайся перевести.
Посмотрим ...
WBR, Alexei K.
Re[9]: boost::thread
От:
Аноним
Дата:
22.06.04 10:47
Оценка:
Здравствуйте, 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. И как одно из самых распространенных заблуждений.
Если используются критические секции, то volatile не нужен.
Если же не используются, как в предлагаемом мной варианте,
то volatile в общем случае нужен.
Да и вообще какая в нашем случае к черту оптимизация возможна?
Вот уж если использовать критические секции вот это и есть
криворкость и антиоптимизация.
