On Thu, 16 Feb 2023 13:45:45 +0100, heby wrote:
> 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.

W standardzie jezyka niby nie ma, ale w praktyce czesto jest.
Widac potrzebne, tylko ze realizacja rózna w róznych systemach,
to nie wsadzili do jezyka.

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

Wielozadaniowosc tez była różna w wielu systemach.
Stad i "nakładki" na języki.

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

Przeciez to nie tylko C ma ten problem.
Wiec jesli są rozwiązania dobre, to mozna je w i C zaimplementowac.
Tylko ... schowac pod volatile, czy osobno.

Bo problemow w zaawansowanych systemach istotnie coraz wiecej.

J.