Есть многопоточное приложение. Под windows на delphi, но думаю это не важно.
Есть ряд глобальных переменных которые могут читать/менять вспомогательные потоки, основной поток их только читает.
Со сложными переменными вроде массивов, записей, объектов все понятно, и критические секции решительно нужны.
А переменные простых типов — Integer/Word/Byte/etc — нужно ли оборачивать их чтение во вход/выход из КС?
С одной стороны логика подсказывает, что чтение и запись должны быть атомарны, тк это одна инструкция CPU, но в современных реалиях, у почти любого процессора есть несколько ядер, не случится ли ситуация когда 2 потока пишут в одну переменную практически одновременно, и в переменной будут записаны старшие байты из одного потока, а младшие из другого?
С точки зрения приложения совсем не важно, какой именно поток запишет данные, важно чтоб они были целостными.

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

CFA>Есть многопоточное приложение. Под windows на delphi, но думаю это не важно.
CFA>Есть ряд глобальных переменных которые могут читать/менять вспомогательные потоки, основной поток их только читает.
CFA>Со сложными переменными вроде массивов, записей, объектов все понятно, и критические секции решительно нужны.
CFA>А переменные простых типов — Integer/Word/Byte/etc — нужно ли оборачивать их чтение во вход/выход из КС?

Если изменяемое значение является счётчиком (или подобным), то без Interlocked* функций не обойтись!
А если у вас просто флаговое предназначение "слова", то достаточно просто выровнять "слово" на 4 байт, что бы обеспечить атомарность.

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

D>Если изменяемое значение является счётчиком (или подобным), то без Interlocked* функций не обойтись!
D>А если у вас просто флаговое предназначение "слова", то достаточно просто выровнять "слово" на 4 байт, что бы обеспечить атомарность.

Не это не счетчик, но и не флаг — а некоторое число, которое будет использоваться в вычислениях основным потоком. Когда любой из потоков его меняет, он не опирается на предыдущее значение. Таким образом не важно, кто записал, важно чтоб число было в точности таким, какое записывал один из потоков, а не "каша" из них.
Получается, если слово не выровнено на 4 байта, то может произойти такая ситуация, когда действительно половина слова записана одним потоком, а вторая половина другим? Полагаю, что пруфы надо искать где-то на сайте интела/амд? Если знаете, был бы признателен за ссылку на оные.

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

D>А если у вас просто флаговое предназначение "слова", то достаточно просто выровнять "слово" на 4 байт, что бы обеспечить атомарность.

И получить проблемы на SMP с раздельными кэшами данных.

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

CFA>Есть многопоточное приложение. Под windows на delphi, но думаю это не важно.
CFA>Есть ряд глобальных переменных которые могут читать/менять вспомогательные потоки, основной поток их только читает.
CFA>Со сложными переменными вроде массивов, записей, объектов все понятно, и критические секции решительно нужны.
CFA>А переменные простых типов — Integer/Word/Byte/etc — нужно ли оборачивать их чтение во вход/выход из КС?
CFA>С одной стороны логика подсказывает, что чтение и запись должны быть атомарны, тк это одна инструкция CPU, но в современных реалиях, у почти любого процессора есть несколько ядер, не случится ли ситуация когда 2 потока пишут в одну переменную практически одновременно, и в переменной будут записаны старшие байты из одного потока, а младшие из другого?
CFA>С точки зрения приложения совсем не важно, какой именно поток запишет данные, важно чтоб они были целостными.

Оборачивать такие переменные в CS не нужно.
Достаточно обеспечить условие, чтобы они, во-первых, были корректно выравненными, а во-вторых,
исключить влияние на них компилятора. Это называется агрессивная оптимизация — без должной подсказки
компилятор может "разобраться" с такой переменной очень своеобразно (держать ее значение в регистре, а
кое-где вообще выкинуть за борт), из-за чего разные потоки будут видеть значение этой переменной по-разному.
В C++ для этой цели существует ключевое слово volatile, но как с этим обстоят дела в Delphi — не в курсе.

Вот где действительно требуется синхронизация — это операции инкремента/декремента и обмена.
Для этих целей в семействе Win32 API специально разработаны Interlocked-функции.
Еще очень советую разобраться с темой "memory reordering" — на x86 эта тема очень
популярна и иногда откидывает ну очень занятные коленца.

Информацию, как всегда, ищите в мануалах на сайте Intel — их можно загружать совершенно свободно.
К огорчению, видимо, для Вас — большая часть информации по системному и низкоуровневому программированию,
как правило, подается в свете C/C++.

ДД>И получить проблемы на SMP с раздельными кэшами данных.

уточню: без аппаратной поддержки когерентности.

Если все равно не согласны, обоснуйте плз.

ДД>>И получить проблемы на SMP с раздельными кэшами данных.
ДД>уточню: без аппаратной поддержки когерентности.
ДД>Если все равно не согласны, обоснуйте плз.

Какие могут быть проблемы? Автор же сказал, что его не волнует, что данные будут не когеренты, его волнует только чтобы они были валидны. Вот если данные представляют собой, скажем счетчик — тогда нужны барьеры.

Здравствуйте, Аноним, Вы писали:

А>Какие могут быть проблемы? Автор же сказал, что его не волнует, что данные будут не когеренты, его волнует только чтобы они были валидны. Вот если данные представляют собой, скажем счетчик — тогда нужны барьеры.

Если, например, модификация и чтение происходит в цикле без барьеров:

while (!quit)
{
   global_variable = <какие-то вычисления>;
   ...
}

то изменение global_variable в одной нити может вообще не дойти до другой нити, даже если она volatile.

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

ДД>>И получить проблемы на SMP с раздельными кэшами данных.
ДД>уточню: без аппаратной поддержки когерентности.

А такое бывает, кроме как в безвременно почившем IA64?

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

ДД>>И получить проблемы на SMP с раздельными кэшами данных.

ДД>уточню: без аппаратной поддержки когерентности.

Сферический конь в вакууме?

ДД>Если все равно не согласны, обоснуйте плз.

Если у процессора нет автоподдержки когерентности, то должен быть механизм ручного её обеспечения с соответствующей поддержкой компилятором. Но это всё равно чистые фантазии, не связанные с реальностью

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, ДимДимыч, Вы писали:

ДД>>>И получить проблемы на SMP с раздельными кэшами данных.
ДД>>уточню: без аппаратной поддержки когерентности.

ЕМ>А такое бывает, кроме как в безвременно почившем IA64?

Хм, в Itanium аппаратная поддержка когерентность была, ЕМНИП.

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

ЕМ>>А такое бывает, кроме как в безвременно почившем IA64?

JR>Хм, в Itanium аппаратная поддержка когерентность была, ЕМНИП.

Так это IA64 и есть.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, Jolly Roger, Вы писали:

ЕМ>>>А такое бывает, кроме как в безвременно почившем IA64?

JR>>Хм, в Itanium аппаратная поддержка когерентность была, ЕМНИП.

ЕМ>Так это IA64 и есть.

Дык и я про то-же

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

ДД>>>И получить проблемы на SMP с раздельными кэшами данных.
ДД>>уточню: без аппаратной поддержки когерентности.

JR>Сферический конь в вакууме?

Как-то пришлось вылавливать баги после портирования системы на один из broadcom'овских MIPS'ов. На синхронизации решили сэкономить, volatile вместо мютексов

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

Memory barrier в примитивах синхронизации это и обеспечивает.

JR>Но это всё равно чистые фантазии, не связанные с реальностью

Согласен, маловероятно, что выпустят что-то из x86 с некогеретными кэшами. Но прикладные приложения, имхо, лучше сразу семантически корректно, без оглядки на аппаратные особенности

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

ДД>Здравствуйте, Jolly Roger, Вы писали:

ДД>>>>И получить проблемы на SMP с раздельными кэшами данных.
ДД>>>уточню: без аппаратной поддержки когерентности.

JR>>Сферический конь в вакууме?

ДД>Как-то пришлось вылавливать баги после портирования системы на один из broadcom'овских MIPS'ов. На синхронизации решили сэкономить, volatile вместо мютексов

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

ДД>Memory barrier в примитивах синхронизации это и обеспечивает.

Ну вообще-то мьютексы, volatile и memory barrier в общем случае несут разную, непересекающуюся семантическую нагрузку, выполняют разные задачи. Мьютексы обеспечивают однопоточную работу участка кода, volatile защищают от агрессивной оптимизации, memory barrier борется с реордерингом. Но разумеется, конкретная наполненость зависит от компилятора и, опосредованно, от процессора.

JR>>Но это всё равно чистые фантазии, не связанные с реальностью

ДД>Согласен, маловероятно, что выпустят что-то из x86 с некогеретными кэшами. Но прикладные приложения, имхо, лучше сразу семантически корректно, без оглядки на аппаратные особенности

Так-то оно так, только это может очень дорого обойтись в части производительности

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

CFA>С одной стороны логика подсказывает, что чтение и запись должны быть атомарны, тк это одна инструкция CPU, но в современных реалиях, у почти любого процессора есть несколько ядер, не случится ли ситуация когда 2 потока пишут в одну переменную практически одновременно, и в переменной будут записаны старшие байты из одного потока, а младшие из другого?

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