атомарные типы в С и C++

в каком смысле атомарные? В отношении многопотоковости? В стандарте этого нет.

Нет и атомарных операций тоже нет.

В стандарте - нет. В АПИ - есть. Как минимум в WinAPI есть атомарные операции типа Interlocked*

Как же быть если нужен аналог atomic_t (из ядра)?

Обычно атомарность реализуют использованием разных ухищрений типа "мьютексов", "семафоров", "критических секций", в зависимости от того, что доступно. В таком случае можно получить "квази-атомарный" код

typedef struct { volatile int counter; } atomic_t;

Из glib-2.10.3/glib/gatomic.c:

void
g_atomic_int_add (volatile gint *atomic,
                  gint           val)
{
  __asm__ __volatile__ ("lock; addl %1,%0"
                        : "=m" (*atomic)
                        : "ir" (val), "m" (*atomic));
}

И далее в том же духе. Можно просто подсесть на glib и использовать функции g_atomic_*

Но лучше, чтоб не тянуть glib, взять из ядра(include/asm/atomic.h)

две команды на асме можно и самому написать

в glib, кстати, не только x86, так что если это важно...

Для каждой архитектуры ? ;)

> typedef struct { volatile int counter; } atomic_t;
В который раз НЕТ - volatile являеться дополнительной мерой, хотя
POSIX и не требует volatile. Для обеспечения атомарных операций 
необходимы барьеры памяти. 

Можешь начать свое изучение этого вопроса отсюда:

http://en.wikipedia.org/wiki/Memory_barrier

---
In C, the volatile keyword is provided to inhibit optimisations which
remove or reorder memory operations on a variable marked as volatile.
This will provide a kind of barrier for interruptions which occur on a
single CPU, such as signal handlers or concurrent threads on a
uniprocessor system. However, the use of volatile is insufficient to
guarantee correct ordering for multiprocessor systems because it only
impacts reorderings performed by the compiler, not those which may occur
at runtime such as those performed by the CPU.
---

А далее по ссылкам.

>Для обеспечения атомарных операций необходимы барьеры памяти.

Ранние модели процессоров не поддерживают инструкции sfence/lfence/mfence , а также prefetch, prefetchw и т.д.

>> typedef struct { volatile int counter; } atomic_t;

>В который раз НЕТ - volatile являеться дополнительной мерой, хотя POSIX и не требует volatile.

Естественно, что использовать это так просто (atomic_t->counter++,etc) нельзя . Смотри /usr/src/linux/include/asm-<arch>/atomic.h

> Ранние модели процессоров не поддерживают инструкции 
> sfence/lfence/mfence , а также prefetch, prefetchw и т.д.

И что? Барьер памяти - это такое абстрактное понятие, не притянутое
к кокой либо конкетной конкретной архитектуре.

> Естественно, что использовать это так просто (atomic_t->counter++,etc) 
нельзя . Смотри /usr/src/linux/include/asm-<arch>/atomic.h

Естественно для кого? Для меня да, но не для автора темы.

>И что? Барьер памяти - это такое абстрактное понятие, не притянутое
к кокой либо конкетной конкретной архитектуре.

Пример реализации в студию.

RTFM на свою платформу :)

xnix (*) (23.08.2006 20:06:55):

Как-то незаметно обсуждение скатилось с атомарных типов на атомарные операции...

Под POSIX'ом смело можно считать, что все целые типы -- атомарные (если есть выравнивание на слово).

Атомарные операции никаких барьеров не требуют.

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

В будущих стандартах C++ планируется снабжать операции над волатильными переменными нужными барьерами, а Жаба это уже делает.

На gcc атомарные операции и барьеры обычно лепятся на встроенном ассемблере, а icc для Итаниума предоставляет соответствующие интринсики.

> не притянутое к кокой либо конкетной конкретной архитектуре.

> RTFM на свою платформу :)

Я это к тому , что могут быть такие архитектуры, на которых барьеры памяти реализовать нельзя.

> Атомарные операции никаких барьеров не требуют.
В контесте С/C++ понятия атомарной операции не существует ( как и
понятия атомарный тип ), атомарность как раз и достигается барьерами.


> В будущих стандартах C++ планируется снабжать операции над
волатильными переменными нужными барьерами

С трудом могу себе такое представить, где об этом можно почитать?

2aton:

> В контесте С/C++ понятия атомарной операции не существует ( как и понятия атомарный тип ), ...

В _стандарте_ этого нет, но на практике во всех существующих POSIX системах все целые типы атомарны (если правильное выравнивание).

Aтомарных операций в С/C++ не существует. Но точно также не существует барьеров.

> ... атомарность как раз и достигается барьерами.

Атомарность операций в контесте С/C++ достигается блокировками. Блокировки могут требовать берьеров, а могут и не требовать, зависит от процессора.

>> В будущих стандартах C++ планируется снабжать операции над волатильными переменными нужными барьерами

> С трудом могу себе такое представить, где об этом можно почитать?

Не помню, где читал. По ключам volatile C++ java barrier нагуглилось: http://en.wikipedia.org/wiki/Memory_barrier , см в конце:

"In Java version 1.5 (also known as version 5), the volatile keyword is now guaranteed to prevent certain hardware and compiler re-orderings, as part of the new Java Memory Model. Proposals have been made to extend C++ in a similar fashion in some future revision."

Возможно, я не совсем прав, речь идет лишь о предложении.

Die-Hard(*) (24.08.2006 17:10:55):

> На Итаниумах, как я понимаю, достаточно просто атомарной операции над волатильной переменной, барьеры не нужны.

Неправильно я понимал, и на Итаниумах они нужны :(

Про atomic operations и memory barriers хорошо написано в документации к ядру - atomic_operations.txt. Архитектура AMD64 не требует никаких барьеров, а powerpc, sparcv9 и itanium - требуют.

>>Я это к тому , что могут быть такие архитектуры, на которых барьеры >>памяти реализовать нельзя.

Практически на всех архитектурах есть инструкция для упорядочивания store/load операций (то есть барьер), другое дело, насколько она "тяжеловесная".

Самая слабая модель памяти у архитектуры Alpha, но даже там есть барьеры.

> Самая слабая модель памяти у архитектуры Alpha, но даже там есть барьеры.

Именн,о, что слабая. Как раз на Альфе -- самое сложное переупорядочивание. И там барьеры даже в интринсиках наитивного компилера.