[C/C++] Атомарные переменные

мне что-то кажется, что атомарными операциями должна операционная система заниматься... в POSIX надо искать

что значит определение?

typedef int atomic_type;

а так нашел уже sig_atomic_t;

я не думаю что это стандарт языка

Еще бы хотелось атомарных операций над sig_atom_t, но их кажется нет. Все это конечно можно сэмулировать используя мутексю, но хочется чтобы небыл переход в kernel-space.

>я не думаю что это стандарт языка

Да мне не нужен стандарт мне нужно переносимое определение, чтобы оно было и в glibc и в uclibc.

хм. в посиксе есть синлг-блокировки (если я не напутал чего)

они в userspace'е

и критические секции по моему тоже

http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/Atomic-Builtins.html

>хм. в посиксе есть синлг-блокировки (если я не напутал чего)

Да там есть спин блокировка. Но сейчас посмотрел в uclibc там она не реализована.

>и критические секции по моему тоже

Сейчас написал тестовую программу и запустил ее через strace и действительно никаких системных вызовов. Ну тогда можно и мутексы использовать.

Спасибо за ссылку.

> написал тестовую программу и запустил ее через strace и действительно никаких системных вызовов. Ну тогда можно и мутексы использовать.

futex'ы (на которых реализованы mutex'ы) не всегда уходят в ядро.

>futex'ы (на которых реализованы mutex'ы) не всегда уходят в ядро.

Спасибо за наводку. Все таки придется в кишки лезть.

Посмотри в openmp, там есть прагмы для атомарности операций. Это достаточно переносимо и поддерживается в нескольких компиляторах и на нескольких платформах (http://openmp.org/wp/openmp-compilers/).

Код будет выглядеть примерно так:

int a;

#pragma omp atomic a += 10;

> Все таки придется в кишки лезть.

Разве что для самообразования. Я бы сделал тупую версию InterlockedIncrement на mutex, и, если бы когда-нибудь она стала узким местом, переписал ее на атомарные инструкции. "Преждевременная оптимизация" и всё такое.

> Естль в glibc/uclibc определение атомарного типа данных?

Почитал тред -- ничего не понял ... :-)

Для gcc любой целый тип является атомарным.

Атомарные типы не имеют ничего общего с атомарными операциями.

На x86-64 на все случаи жизни достаточно атомарного инкремента -- к сожалению, в стандарте Це его нет. Все современные компиляторы имеют соответствующие интринсики. Вот полезная штука, там можно всё посмотреть: http://www.hpl.hp.com/research/linux/atomic_ops/using_atomic_ops.php4

Все современные Цешные компиляторы (теоретически) правильно обрабатывают обращение к volatile переменным (в смысле, правильно расставляют барьеры -- на x86-64 их вообще не надо, но на Итанике, например, без них -- никак).

При использовании pthread все будет работать как надо, не требуется никаких volatile, etc...

Футексы не сразу уходят в ядро, но сначала пытаются в юзерспейсе взять спинлок. Если не удалось, только тогда в ядро уходят.

По любому, все, что окружено мутексами, будет "атомарно".

> Почитал тред -- ничего не понял ... :-)

Зачем тогда писать в него такой большой пост?

Атомарные операции есть в builtin-ах, gcc. В других компиляторах они тоже могут быть, но о переносимости придётся позаботиться руками (если надо). Атомарные операции на мьютексах -- результат фатального и необратимого поражения головного мозга. Капча dowctor как бы намекает.

// pppp

> Зачем тогда писать в него такой большой пост?

Судя по твоему ответу, ты тоже мало что понял ;)

> Атомарные операции есть в builtin-ах, gcc. В других компиляторах они тоже могут быть, но о переносимости придётся позаботиться руками (если надо).

Вообще-то, именно это я и написАл.

А чего я не понял -- топикстартер изначально спрашивал про атомарные типы, потом обсуждение незаметно перешло на атомарные операции. Между тем, атомарных типов -- сколько угдно (де-факто для почти всех компиляторы на почти всех платформах можно смело полагать любой целый тип атомарным), а атомарных операций нет ни в стандарте, ни в "стандарте де-факто". Даже интринсики у одного и того же компилятора могут различаться на разных платформах. Проще всего заюзать готовую библиотеку -- я ссылку привёл.

> Атомарные операции на мьютексах -- результат фатального и необратимого поражения головного мозга.

Во-первых, обкладка некими блокировками атомарных операций -- единственный способ, если оставаться в рамках POSIX'а. В Линуксе с ядром >=2.5 разницы между мутексами и спинлоками практически не будет.

Во-вторых, атомарная операция -- не самоцель, а необходимая для алгоритма фенечка. В 90% случаев атомарные арифметические операции нужны для "атомизации" более "толстых" операций, а мутексы для этого и придуманы. Судя по нежеланию топикстартера уходить в ядро, именно это ему и надо. Так вот, с современным линуксовым ядром мутекс в ядро и не пойдет, если можно, в юзерспейсе спинлок крутанёт.

> Футексы не сразу уходят в ядро, но сначала пытаются в юзерспейсе взять спинлок

что подразумевается под фьютексами? futex (man 2 futex) сразу уходит в ядро

> futex (man 2 futex) сразу уходит в ядро

Нет. man 2 futex :-)

Hint: "futex - Fast Userspace Locking system call"

Кстати, полезно сделать RTFM насчёт man 4 futex ;)

> Нет. man 2 futex :-) 
 
futex - обертка libc над sys_futex ;)
задача - синхронизация и управление процессами
другое дело, что с помощью данного механизма реализуется low-level семантика блокировок: ожидание в случае невозможности захвата
поэтому я и хотел уточнить, что конкретно подразумевается под фьютексами: общая концепция man 7 futex или конкретный API man 2 futex ;)

> что конкретно подразумевается под фьютексами: общая концепция man 7 futex или конкретный API man 2 futex

Концепция, конечно. API в pthread сидит.

man 2 это же ман по syscalls. Действительно, странно было бы если syscall не сразу уходил в ядро:)