W dniu 10.02.2011 19:35, Zbych pisze:
> W dniu 2011-02-10 17:00, Michoo pisze:
>> W dniu 10.02.2011 16:16, Zbych pisze:
>>> Nie używaj cli i sei do robienia sekcji atomowych, te makra nie są
>>> zabezpieczone przed optymalizacją i kompilator może zmienić kolejność
>>> instrukcji (choć oczywiście nie musi).
>> Chyba nie - definicja wyglądają tak:
>> # define sei() __asm__ __volatile__ ("sei" ::)
>> # define cli() __asm__ __volatile__ ("cli" ::)
>>
>> Co zabrania kompilatorowi zamiany kolejności ewaluacji wyrażeń.
>
> volatile zabrania usunięcia, optymalizacji, ale nie zabroni przesunięcia
> czegoś co jest pomiędzy sei i cli, czyli z kodu
> cli();[coś];sei();
> może wyjść:
> cli();sei(); [coś];
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.
Gdy [coś] operuje na zmiennych volatile wszystko musi działać a
jednocześnie nie ma konieczności synchronizacji wszystkich rejestrów jak
przy klasycznej barierze.

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

>
>> 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. W sumie jak się głębiej
zastanowić to to jest sensowne:
cli();[operacje na volatile]sei();
- działa jak należy
cli();[dowolne operacje i synchronizacja zmiennej współdzielonej]sei();
- też działa
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ę

--
Pozdrawiam
Michoo