LINUX.ORG.RU

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

dilmah ★★★★★
()
Ответ на: комментарий от anonymous

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

mst_72
()
Ответ на: комментарий от anonymous

Из 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_*

erDiZz
()
Ответ на: комментарий от erDiZz

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

erDiZz
()
Ответ на: комментарий от xnix

> 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.
---

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

aton
()
Ответ на: комментарий от aton

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

Ранние модели процессоров не поддерживают инструкции 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

xnix ★★
()
Ответ на: комментарий от xnix

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

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

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

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

aton
()
Ответ на: комментарий от aton

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

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

xnix ★★
()
Ответ на: комментарий от xnix

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

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

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

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

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

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

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

Die-Hard ★★★★★
()
Ответ на: комментарий от aton

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

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

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

xnix ★★
()
Ответ на: комментарий от Die-Hard

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


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

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

aton
()
Ответ на: комментарий от aton

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 ★★★★★
()
Ответ на: комментарий от Die-Hard

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

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

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

Die-Hard ★★★★★
()
Ответ на: комментарий от Die-Hard

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

Motl
()
Ответ на: комментарий от Motl

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

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

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

Motl
()
Ответ на: комментарий от Motl

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

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

Die-Hard ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.