On 16/02/2023 12:46, Grzegorz Niemirowski wrote:
>> Do tego, co piszesz, służa bariery/fence.
> Możesz podać przykład na ATmegę?

Nie. Bo mowa o C ogólnie. Szczególne dla AVR stosujemy sztuczki
asemblerowe, nielegalne w danej sytuacji słowa kluczowe itd itp. Sam
fakt użycia "przerwania" jest z definicji nieistniejącym bytem w C i
wymaga poza-językowych narzędzi, bo sam język nie dostarcza wsparcia dla
przerwań wiec trudno tez, aby dostarczał mechnizmy ich wspierania.

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

Jeśli pytałbyś o ogólny C++ to zasugeroeałbym okolice:

https://mariadb.org/wp-content/uploads/2017/11/2017-
11-Memory-barriers.pdf

Czy poprawna implementacja na AVR istnieje - nie wiem. Może kiedyś zerknę.

>> Jeśli potraktujesz przerwania jako wątki preemptive, to tak naprawdę
>> piszesz o zagadnieniu dostępu do zmiennych przez kilka watków. Tego
>> zagadnienia *NIE* należy rozwiązywać za pomocą volatile, ono nie
>> powstało do tego i sie do tego NIE nadaje.
> Wiem. Nic o wątkach nie pisałem.

Mimo to przerwanie jest czymś identycznym z wątkiem preemptive. Ma te
same konsekwencje i dla dużych procesorów, szczególnie wielordzeniowych,
niesie z sobą dokładnie te same zagrożenia, co wątki. I nie jest tak, że
świat kończy się na 8051. Wielordzeniowe procesory embedded to nic
specjalnie dziwnego.

Tam, wszyscy programiści od volatile, wybiją sobie zęby o protokoły
synchronizacji cache, out-of-order execution itd itp.

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.