heby <h...@p...onet.pl> napisał(a):
> Tam, wszyscy programiści od volatile, wybiją sobie zęby o protokoły
> synchronizacji cache, out-of-order execution itd itp.

Ale ja nic nie mówiłem o cache procesora ani kolejności operacji. Chodzi o
problem jaki wprowadza kompilator optymalizując dostęp do zmiennej poprzez
przeniesienie jej z RAM-u do rejestru w jakimś fragmencie kodu. Żadne
bariery na to nie pomogą. Powszechnie problem ten rozwiązuje się stosując
volatile.

> Uwaga o volatile dotyczy *języka* C a nie implementacji tego na AVR.

To nie musi być AVR. Wspomniałem o nim, bo on nawet nie ma operacji do
barier jak np. ARM (DSB, DMB, ISB).

> Sam fakt użycia "przerwania" jest z definicji nieistniejącym bytem w C

Kogo to obchodzi? Jak na złość w prawie każdym procesorze są przerwania.

> PS. Zaznaczam, że nic nie pisałeś o AVR w poprzednim poście, wiec w
> ogólnym wypadku, volatile nie może i nie powinno być uzywane w celu
> synchronizacji zmiannych w przerwaniach. W szczególnym, kiedy znasz
> konkretną architekturę, być może.

A dlaczego nie powinno i co polecasz w zamian? Nie podałeś żadnego argumentu
przeciw volatile. Cały czas chodzi o programy bare metal, bez schedulera.
volatile jest powszechnie stosowanym oraz polecanym rozwiązaniem problemu
optymalizacji na MCU, o którym wspomniałem poprzednio, a doprecyzowałem na
początku tego posta, żeby było jasne o co chodzi. I jakoś w Internecie nie
widzę polemiki z tym polecaniem volatile, z wyjątkiem Twoim postów. Pomijam
oczywiście przypadki używania volatile do innych problemów, do których się
nie nadaje, jak atomowość.

Więc mamy kod:

int z = 0;

int main() {
while(!z);
return 0;
}

isr_handler() {
z = 1;
}

Przy kompilacji z -O0 nie ma problemu, przerwanie przerwie pętlę while. Przy
wyższej optymalizacji pętla może czytać kopię zmiennej i przez to nie
zauważyć jej modyfikacji. volatile łatwo i szybko usuwa ten problem. Mam
nadzieję, że teraz już jest wszystko jasne i w końcu dowiem się jakie
straszne efekty spowoduje tutaj wprowadzenie volatile oraz co jest lepszego.

--
Grzegorz Niemirowski
https://www.grzegorz.net/