On 16/02/2023 19:11, Grzegorz Niemirowski wrote:
>> Przecież zlinkowałem arykuł, w którym masz jasno wypisane powody i
>> ostrzeżenie.
> I w sumie jako rozwiązanie podają std::atomic. Ciekawe czy atomic z C
> też może być.

A co broni użyć C++, szczególnie na nowej arch? Nawet na AVR to zmiana 2
literek na dwa + w nazwie kompilatora i strata bodaj 4 bajtów na
dodatkową sekcję, którą można łatwo usunąć, jak ktoś sępi. Więc na arch,
gdzie atomic ma implementację, to powinno kosztować asymptotyczne zero.

>>> Cały czas chodzi o programy bare metal, bez schedulera.
>> Przerwania to multitasking, taki sam jak w schedulerze preemptive.
> Chodziło o to, że jak jest scheduler to zwykle też masz pod ręką
> semafory, kolejki itd.

Ich istnienie jest rozdzielne. Do tego stopnia, że trafiłem kiedyś na
urządzenie o nazwie "Tiger" zawierajace "TigerBASIC", taki panel do
kontroli automatyki, z wyświetlaczem graficznym. Gdzie rozdział
poświęcony miltithread miał opis 1 funkcji tworzącej wątek i kończył się
na "należy zwrócić uwagę na dostępie do zmiennych w innych wątkach". I
wsio na temat synchronizacji.

>> W pierdołowatych małych cpu zapewne tak. W dużych absolutnie nie.
>> Pisząc relatywnie duże programy, o dużej złożoności, z masą wątków i
>> wymianą danych między nimi, nie miałem okazji użyć volatile ani razu.
>> Z ciekawostek: w poważnych firmach słowo volatile jest wyłapywane
>> przez linter kodu i wymaga zgody komisji za zielonym suknem.
> Miałem właśnie na myśli MCU.

A ja wskazuje, że granica między dużym systemem i uC/MCU zaciera się
coraz szybciej. Mam przed sobą pdf dwurdzeniowego ARM za normalne $. Do
migania diodą nadaje się tak samo jak AVR. Może nawet konsumuje mniej
energii, nie zdzwiłbym się.

>> Niezliczona ilość postów/stron wyjasnia, dlaczego volatile nie jest
>> tym, o czym myślisz, że do czego jest.
>> Serio, nie zauważyłes?
> Ale cały czas mi chodzi o ten problem cache. Wiem dobrze, że volatile
> nie rozwiązuje zacytowanych wyżej problemów.

volatile źle rozwiązuje równiez "ten problem z cache" w sensie
optymalizacji. Bo zabrania *zawsze* optymalizacji danej zmiennej,a nie
tylko w miejscu, gdzie jest błędem logicznym.

> Zgadza się. Niemniej dlatego wspomniałem, że problem dotyczy MCU.

MCU za chwile będą takie jak duże systemy. Duże systemy idą w szerokość
(ilośc rdzeni) to samo czeka uC. Prawdę mówiąc bardzo mi szkoda, że
Parallax Propeller nie dał rady stać się popularnym, to był bardzo
interesujacy CPU do aplikacji real-time.