W dniu 2011-02-11 12:43, Michoo pisze:
> 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.)

Co prawda c++, a nie c, ale dzięki za podesłanie tego. Miło wiedzieć, że
jest to w ogóle ustandaryzowane.

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

Fajne :-)