Имеет ли смысл заключать в mutex-ы 1 операцию присваивания вида переменная=константа или переменная=переменная на C? (типы примитивные — int/float/итп). Иными словами — можно ли полагаться на ее атомарность? Где это написанно?
Linux/pthread-s.

PS lock xchg ??

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

S>Имеет ли смысл заключать в mutex-ы 1 операцию присваивания вида переменная=константа

Нет, а зачем?

S>или переменная=переменная на C? (типы примитивные — int/float/итп). Иными словами — можно ли полагаться на ее атомарность? Где это написанно?

В общем случае, операции не атомарны. Но переменные могут быть и в регистрах, тогда проблем не будет.

S>Linux/pthread-s.

Про это не знаю.

S>PS lock xchg ??

Операция не требует lock префикс.

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

S>Имеет ли смысл заключать в mutex-ы 1 операцию присваивания вида переменная=константа или переменная=переменная на C? (типы примитивные — int/float/итп). Иными словами — можно ли полагаться на ее атомарность? Где это написанно?
S>Linux/pthread-s.

S>PS lock xchg ??
Для атомарных операций над примитивами лучше использовать функционал asm/atomic.h. Это будет работать гораздо быстрее, чем через мьютексы и гораздо переносимее, чем самостоятельная реализация.

S>Имеет ли смысл заключать в mutex-ы 1 операцию присваивания вида переменная=константа или переменная=переменная на C? (типы примитивные — int/float/итп). Иными словами — можно ли полагаться на ее атомарность? Где это написанно?

Вроде бы, если она неправильно выровнена, то операции с ней могут быть неатомарными.

Кроме того, существенно, как она используется.

Если это, скажем, текущее измеренное значение температуры, то, может, и не имеет.

А если это какой-то флажок, скажем

g_data1 = &data1;
g_data2 = &data2;
g_all_data_ready = true;  // ну уж один байт не может быть неатомарным :)

то очень даже стоит и не только запись, но и чтение.
Почему? Например:
http://www.javaworld.com/javaworld/jw-02-2001/jw-0209-double.html

On Thu, 26 Jan 2006 18:49:17 -0000, shestero <36780@users.rsdn.ru> wrote:

> Имеет ли смысл заключать в mutex-ы 1 операцию присваивания вида переменная=константа или переменная=переменная на C? (типы примитивные — int/float/итп). Иными словами — можно ли полагаться на ее атомарность? Где это написанно?
> Linux/pthread-s.

Имеет смысл. Даже если операция атомарна, требуется обеспечить visibility, т.е. чтобы остальные процессоры узнали об изменение памяти, сделанным другим процессором. Для этого используют memory barrier. lock/unlock мьютекса — memory barrier.

--
Maxim Yegorushkin

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

DM>Для атомарных операций над примитивами лучше использовать функционал asm/atomic.h. Это будет работать гораздо быстрее, чем через мьютексы и гораздо переносимее, чем самостоятельная реализация.

Не совсем верное утверждение.

Я когда-то на ядре 2.4 столкнулся с тем, что атомик функции работают на одно мпроцессоре, т.е. при работе на SMP — нужны барьеры, см Re: многопоточность. атомарность операции присваивания.

Автор: MaximE
Дата: 27.01.06

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

S>Имеет ли смысл заключать в mutex-ы 1 операцию присваивания вида переменная=константа или переменная=переменная на C? (типы примитивные — int/float/итп). Иными словами — можно ли полагаться на ее атомарность? Где это написанно?
S>Linux/pthread-s.

S>PS lock xchg ??

используй Interlocked операции
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/interlockedincrement.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/interlockedcompareexchange.asp

S>Имеет ли смысл заключать в mutex-ы 1 операцию присваивания вида переменная=константа или переменная=переменная на C? (типы примитивные — int/float/итп). Иными словами — можно ли полагаться на ее атомарность? Где это написанно?
S>Linux/pthread-s.
S>PS lock xchg ??

Вне контекста того что ты делаешь — это сказать невозможно. Атомарность каких-любо модификаций вообще нужна только в том случае, когда существует concurrency (борьба потоков за ИЗМЕНЕНИЕ данных) И только в том случае, когда возникает нежелательный side-effect.

AR>Вне контекста того что ты делаешь — это сказать невозможно. Атомарность каких-любо модификаций вообще нужна только в том случае, когда существует concurrency (борьба потоков за ИЗМЕНЕНИЕ данных) И только в том случае, когда возникает нежелательный side-effect.

Т.е. если один поток только пишет, а второй только читает, атомарность по-вашему не нужна — за ИЗМЕНЕНИЕ-то они не борются?
Всё-таки читать что-то наполовину записанное тоже неправильно.

Если переменные разделяемы, то следует.

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

А>Т.е. если один поток только пишет, а второй только читает, атомарность по-вашему не нужна — за ИЗМЕНЕНИЕ-то они не борются?

Атомарности недостаточно на smp.

AR>>Вне контекста того что ты делаешь — это сказать невозможно. Атомарность каких-любо модификаций вообще нужна только в том случае, когда существует concurrency (борьба потоков за ИЗМЕНЕНИЕ данных) И только в том случае, когда возникает нежелательный side-effect.
А>Т.е. если один поток только пишет, а второй только читает, атомарность по-вашему не нужна — за ИЗМЕНЕНИЕ-то они не борются?
А>Всё-таки читать что-то наполовину записанное тоже неправильно.

Выше мной было написано И когда возникает нежелательный side-effect.
Синхронизация только по тому поводу что что-то там "наполовину записано" не нужна, если это не отражается на желаемом поведении алгоритма/программы.

Простой пример, который я уже когда-то уже кому-то приводил.
Допустим, один поток (или много таких) рисует на экране некий объект. Ну скажем, картинку-спрайт. Рисует он считывая две координаты X,Y. Другой поток, или даже множество потоков постоянно перезаписывают эти две переменные X,Y. Так вот, в моей архитектуре записывающий поток может как угодно переписывать переменные X,Y. Из того что он успеет изменить только X, или только Y координату объекта, а читающий поток прочитает "наполовину измененнные данные" — ничего страшного абсолютно не будет. Да, объект на экране нарисуется чуть в другой позиции. Но мне это совершенно приемлемо. Причем это допустимо не только когда объект рисуется совершенно случайно, но и в т.ч. когда последовательность координат представляет собой некую гладкую функцию. Из того что произошла рассогласованность X,Y — ничего страшного не произойдет в данном случае.

Этот случай можно расширить на МАССИВ координат X,Y. Все будет аналогично — синхронизация не потребуется, никаких эффектов не возникает, даже если массив координат изменен всего лишь наполовину, и даже если при этом изменена лишь какая-то одна координата X.

Пример выше можно распространить и на C++ объекты — не всегда несогласованное изменение данных класса фатально для пользователей класса.
И также на другие случаи — например изменение циклического аудио-буфера. Один поток читает, другой пишет. Между ними нужна логическая программная синхронизация (по-очередность) но вовсе не синхронизация доступа к буферу.

S>>PS lock xchg ??

_>используй Interlocked операции


вроде речь про Линукс функций винапи там нет

для известной машинной архитектуры несложно написать ассемблерную вставку
(если нет либы которая уже содержит эти ф-ции)

On Mon, 30 Jan 2006 13:15:36 -0000, Awaken <12048@users.rsdn.ru> wrote:

> S>>PS lock xchg ??
>
> _>используй Interlocked операции
>
>
> вроде речь про Линукс функций винапи там нет

Для gcc достаточно #include <bits/atomicity.h>

--
Maxim Yegorushkin