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. Ja wtykanie volatile
wszędzie gdzie się da uważam co najmniej za lenistwo. 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.

>> Dodatkowo taka konstrukcja nie zmusza kompilatora do zapisania wartości
>> tymczasowych trzymanych w rejestrach do pamięci, więc może się okazać,
>> że zapis wielobajtowej zmiennej nastąpi już przy włączonych przerwaniach.
>>
>> Przykłady można znaleźć na liście dyskusyjnej avr-gcc.
> Masz może linkę? Bo na szybko nie mogłem znaleźć.

Nie chce mi się szukać. 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().

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

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