Здравствуйте, remark, Вы писали:

R>Строго говоря, дело не в многопоточности, а в том, на каких процессорах они выполняются.
R>Если на машине всего один процессор; или все потоки, работающие со счётчиком, привязаны к одному процессору; или к счётчику обращается поток и обработчик сигнала, работающий на этом же потоке, то "Interlocked" использовать нет необходимости
[...]

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

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

Здравствуйте, sidorov18, Вы писали:

S>Здравствуйте, remark, Вы писали:

R>>Строго говоря, дело не в многопоточности, а в том, на каких процессорах они выполняются.
R>>Если на машине всего один процессор; или все потоки, работающие со счётчиком, привязаны к одному процессору; или к счётчику обращается поток и обработчик сигнала, работающий на этом же потоке, то "Interlocked" использовать нет необходимости
S>[...]

S>т.е. если на машине с софтом будет н-ядерный процессор, то вызов ф-ии из разных потоков может выполняться на разных процессорах?

Конечно. А зачем тогда потоки???

S>все потоки привязаны к одному процессу — это как? потоки ведь и так вызываються в процессе.

к одному процессору

S>и что такое обработчик сигнала?

Механизм асинхронного вызова процедур из мира юникс.

Здравствуйте, Николай Ивченков, Вы писали:

НИ>sidorov18:

S>>А если наоборот? volatile оставить, а InterlockedIncrement убрать(компилятор mcvs).

НИ>volatile тут совершенно бесполезен.

Ну в ms specific вроде как гарантируеться атомарность операции с volatile.
из мсдн:

A write to a volatile object (volatile write) has Release semantics; a reference to a global or static object that occurs before a write to a volatile object in the instruction sequence will occur before that volatile write in the compiled binary.

A read of a volatile object (volatile read) has Acquire semantics; a reference to a global or static object that occurs after a read of volatile memory in the instruction sequence will occur after that volatile read in the compiled binary.

только этот кусок несовсем понятен.

Непонятно, как происходит запись id++; т.е. если чтение и запись — это одна операция, то один поток считывает id, инкрементирует и записывает ее — тогда volatile можно использовать вместо "Interlocked" ф-ии.
а если нет — то поток А считал переменную. поток Б считал переменную. поток А инкрементировал и записал переменную. поток Б инкрементировал и записал переменную — в этом случае volatile бесполезен.

Здравствуйте, remark, Вы писали:

R>Механизм асинхронного вызова процедур из мира юникс.

т.е. к Windows приложению это не имеет отношения?

Здравствуйте, sidorov18, Вы писали:

S>Здравствуйте, remark, Вы писали:

R>>Механизм асинхронного вызова процедур из мира юникс.

S>т.е. к Windows приложению это не имеет отношения?

да... хотя... в Windows есть UMS, что в итоге получается примерно то же самое.
Т.е. если несколько UMS контекстов работают на одном ядерном потоке, то такая же ситуация как с потоками.

Здравствуйте, sidorov18, Вы писали:

S>Ну в ms specific вроде как гарантируеться атомарность операции с volatile.

S>из мсдн:
S>

S>A write to a volatile object (volatile write) has Release semantics; a reference to a global or static object that occurs before a write to a volatile object in the instruction sequence will occur before that volatile write in the compiled binary.

S>A read of a volatile object (volatile read) has Acquire semantics; a reference to a global or static object that occurs after a read of volatile memory in the instruction sequence will occur after that volatile read in the compiled binary.

Где тут хоть одно упоминание атомарности?

Здравствуйте, remark, Вы писали:

R>к одному процессору
а, сорри. а это как-то делаеться? т.е. привязка потоков к одному процессору.

Здравствуйте, sidorov18, Вы писали:

S>Здравствуйте, remark, Вы писали:

R>>к одному процессору
S>а, сорри. а это как-то делаеться? т.е. привязка потоков к одному процессору.

SetProcessAffinityMask()/SetThreadAffinityMask()/pthread_set_affinity_np()/processor_bind()

Здравствуйте, remark, Вы писали:

R>Где тут хоть одно упоминание атомарности?

я плохо понял выделенный кусок, если честно. но интересно все же прояснить, что это такое.

Acquire и Release semantics:

An operation has acquire semantics if other processors will always see its effect before any subsequent operation's effect. An operation has release semantics if other processors will see every preceding operation's effect before the effect of the operation itself.

т.е. в данном контексте release означает, что другие процессоры увидят эффект предидущих операций перед операцией над переменной, а acquire — наоборот.
про атомарность ничего не сказано.
но что тогда это означает? что переменная не кешируеться в регистре и всегда осуществляеться доступ к памяти? хотя слова Aquire(можно перевести, как захватить) и Release(освободить) сбивают с толку. напрашиваеться аналогия с мьютексом или критической секцией.

иначе, как может другой процессор увидеть изменения "b", раньше, чем "а" в приведенном ms примере:

 a++;
 b++;

?

Здравствуйте, remark, Вы писали:

R>да... хотя... в Windows есть UMS, что в итоге получается примерно то же самое.
R>Т.е. если несколько UMS контекстов работают на одном ядерном потоке, то такая же ситуация как с потоками.

UMS это User Mode Scheduler?