heby <h...@p...onet.pl> napisał(a):
> 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ć.

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

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

>> I jakoś w Internecie nie widzę polemiki z tym polecaniem volatile
> Bo jej nie szukasz. Google aż krzyczy "nie uzywaj volatile, to nie działa
> jak myślisz".
> Choćby wiki:
> https://en.wikipedia.org/wiki/Volatile_(computer_pro
gramming)
> [...]Furthermore, in C and C++ it does not work in most threading
> scenarios, and that use is discouraged.[...]"
> "[...]Operations on volatile variables are not atomic, nor do they
> establish a proper happens-before relationship for threading. This is
> specified in the relevant standards (C, C++, POSIX, WIN32),[1] and
> volatile variables are not threadsafe in the vast majority of current
> implementations. Thus, the usage of volatile keyword as a portable
> synchronization mechanism is discouraged by many C/C++ groups[...]".
> 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.

> W małym procesorze tak.
> Teraz weź duży procesor. Być może Ci zaskoczy, że jeśli to przerwanie to
> inny wątek na innym rdzeniu, to mimo, że rdzeń zapisze z = 1, to pętla
> nigdy się nie zakończy. Bo możesz mieć system ze słabą koherencją cache i
> bez bariery/fence informacja nigdy nie zostanie zsynchronizowana z
> lokalnymi cache obu rdzeni. Albo ciekawoski z przestawianiem zapisów,
> kiedy jeden rdzeń widzi zapis w innej kolejnosci niż wykonany w sąsiednim
> rdzeniu.
> Swoją drogą ten problem jest trudny do zauważenia przez przeciętnego
> wciskacza klawiszy, bo x86 jest wyjątkowo tolerancyjny dla dziadowskiego
> kodu. Tam to działa przypadkiem i wiele osób ma podejrzenie, że nie bez
> powodu takie decyzje projektowe podjęto: łatwiej było zaprojektować
> tolerancyjny procesor niż liczyć na poprawianie miliardów lini kodu po
> kiepskich programistach.

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

> Powoduje: zablokowanie optymalizacji *całej* zmiennej, wszędzie oraz nie
> usuwa innych problemów z wątkowością, takich jak weak memory ordering czy
> synchronizacja cache.
> Ogólnie działa tylko na małych systemach, gdzie nie ma tego typu zagrożeń,
> co powoduje że volatile jest narzędziem workaroudującym prawidłowe metody,
> a nie metodą samą w sobie.
> Na większych sens jest zerowy, poza dostępem do rejestrów.

OK, tutaj zgoda.

> Jak już musisz mieć niskopoziomowo to wyjasnione, to może zerknij tutaj:
> https://www.kernel.org/doc/html/latest/process/volat
ile-considered-harmful
> .html

Dzięki.

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