W dniu 11.02.2011 08:36, Zbych pisze:
> W dniu 2011-02-10 22:31, Michoo pisze:
>
>> Tylko jeżeli [coś] jest kiepskim kodem ;) - Używanie w sekcji krytycznej
>> czegoś co nie jest volatile i nie zawiera bariery na przesyłanej
>> zmiennej jest sprzeczne zarówno ze standardem jak i ze zdrowym
>> rozsądkiem.
>
> Pokaż mi gdzie jest to napisane w standardzie.
C++:
When the processing of the abstract machine is interrupted by receipt of
a signal, the values of objects with type other than volatile
sig_atomic_t are unspecified, and the value of any object not of
volatile sig_atomic_t that is modified by the handler becomes undefined.

Czyli przerzucanie program<->przerwanie czegoś innego niż "volatile
sig_atomic_t" w myśl standardu nie jest zdefiniowane. Ale jednocześnie:

Accessing an object designated by a volatile lvalue (3.10), modifying an
object, calling a library I/O function, or calling a function that does
any of those operations are all side effects, which are changes in the
state of the execution environment. Evaluation of an expression might
produce side effects. At certain specified points in the execution
sequence called sequence points, all side effects of previous
evaluations shall be complete and no side effects of subsequent
evaluations shall have taken place.)

W związku z tym gcc/g++ daje gwarancję na prawidłowe przekazanie
obiektów volatile.
http://gcc.gnu.org/onlinedocs/gcc/Volatiles.html


> Ja wtykanie volatile
> wszędzie gdzie się da uważam co najmniej za lenistwo.
Ja za błąd w sztuce - nie dość, że optymalizacje psuje to jeszcze
wprowadza bardzo trudne do wykrycia błędy (przesyłanie wielobajtowych
obiektów volatile bez synchronizacji a jedynie licząc, że samo volatile
wystarczy) Niemniej *nie oznaczenie* obiektu przekazywanego jako
volatile to już lampka ostrzegawcza, bo trzeba dodatkowo pamiętać o
barierach.

> Jak już muszę użyć
> to często robię unię zmiennej volatile i bez volatile. Dzięki czemu nie
> mam nadmiarowego kodu np. w przerwaniach.
Ja zazwyczaj używam volatile do samego przekazania i osobne zmienne "po
obu stronach" albo nie daję volatile i pamiętam o synchronizacji ;)


> Musisz przejrzeć daty w okolicach dodania makr
> ATOMIC do biblioteki. Te makra powstały właśnie po tym jak ludzie
> zaczęli zgłaszać błędy związane przenoszeniem operacji poza blok
> cli()-sei().
Ok, będę miał chwilę to poszukam.


>>>> Dziwne swoją drogą, że nie jest to zapisane na wszelki wypadek jako
>>>> # define sei() __asm__ __volatile__ ("sei" :::"memory")
>>>
>>> No właśnie o tę barierę na pamięci chodzi.
>> Tylko bariera jest wolna i nieoptymalna.
>
> Ta bariera nie jest wolniejsza niż używanie volatile. Wymusza tylko
> zrzut i pobranie zmiennych.
Wszystkich zmiennych. Używanie volatile jest wolne tylko w odniesieniu
do tego jednego obiektu.

Napisałem kiedyś makro, które robiło barierę na podanej zmiennej -
dziwię się, że nie ma czegoś takiego w bibliotece:
#define SYNC_VARIABLE(var) __asm__ __volatile__ ("" :"=m"(var):"m"(var))

>
>> cli();[operacje bez synchronizacji]sei();
>> - robi to co programista napisał a nie to co chciał, ale C jest znane z
>> tego że pozwala się postrzelić w stopę
>
> Tia, temat na kolejne bicie piany :-)
Po coś te grupy dyskusyjne powstały ;)

--
Pozdrawiam
Michoo