-
Path: news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!2.eu.feeder.erj
e.net!feeder.erje.net!feeds.phibee-telecom.net!newsreader4.netcologne.de!news.n
etcologne.de!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.ams4!peer.am
4.highwinds-media.com!news.highwinds-media.com!newsfeed.neostrada.pl!unt-exc-01
.news.neostrada.pl!unt-spo-a-01.news.neostrada.pl!news.neostrada.pl.POSTED!not-
for-mail
From: "Grzegorz Niemirowski" <g...@g...net>
Newsgroups: pl.misc.elektronika
References: <16qbnwht7z74n.8802zax2iioq$.dlg@40tude.net>
<63dad430$0$9589$65785112@news.neostrada.pl>
<trelrs$g0p$1$Janusz@news.chmurka.net>
<trgbkf$st9$1$PiotrGalka@news.chmurka.net>
<63dbd22e$0$9601$65785112@news.neostrada.pl>
<ts6rps$roo$1$PiotrGalka@news.chmurka.net>
<63e9f424$0$19625$65785112@news.neostrada.pl>
<tsg6eb$96a$1$PiotrGalka@news.chmurka.net> <tsgv8m$2kn8s$1@dont-email.me>
<tsiqth$55n$1$PiotrGalka@news.chmurka.net> <tsj9if$2v62r$1@dont-email.me>
<a...@n...neostrada.pl>
<tsjl9d$30gq5$1@dont-email.me>
<63ed6483$0$9597$65785112@news.neostrada.pl>
<tski4a$365ef$1@dont-email.me>
<63ee1784$0$9589$65785112@news.neostrada.pl>
<tsl8hv$38gns$1@dont-email.me>
<63ee3c75$0$19611$65785112@news.neostrada.pl>
<tsln7m$3a7hn$1@dont-email.me>
Subject: Re: C++ ośla łączka
Date: Thu, 16 Feb 2023 19:11:48 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: OE PowerTool 4.5.5
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7681
X-WWW: https://www.grzegorz.net/
Lines: 78
Message-ID: <63ee71e2$0$19606$65785112@news.neostrada.pl>
Organization: Telekomunikacja Polska
NNTP-Posting-Host: 89.65.244.230
X-Trace: 1676571106 unt-rea-a-02.news.neostrada.pl 19606 89.65.244.230:62137
X-Complaints-To: a...@n...neostrada.pl
X-Received-Bytes: 5409
Xref: news-archive.icm.edu.pl pl.misc.elektronika:778375
[ ukryj nagłówki ]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/
Następne wpisy z tego wątku
- 16.02.23 19:22 Marek
- 16.02.23 19:27 Marek
- 16.02.23 19:56 heby
- 16.02.23 19:57 heby
- 17.02.23 02:28 JDX
- 17.02.23 02:35 JDX
- 17.02.23 07:17 Marek
- 17.02.23 09:18 heby
- 17.02.23 09:30 J.F
- 17.02.23 10:17 JDX
- 17.02.23 10:28 heby
- 17.02.23 10:41 JDX
- 17.02.23 14:31 J.F
- 17.02.23 14:51 heby
- 17.02.23 16:21 Grzegorz Niemirowski
Najnowsze wątki z tej grupy
- Thunderbird i dysk...
- opornosc falowa
- Bateria 9V 6F22, alkaliczna v cynkowa, samorozładowanie, bateria wysokiej trwałości do miernika
- Tani zakup z ali?
- w czasach LED komary mają ciężko
- walizka z kodami
- Rejestrator temperatur - termopara, siec
- Router LTE z możliwością zmian MTU
- Fajny film widziałem...
- Jaka ładowarka sieciowa do Iphona?
- Taśma izolacyjna do prac elektrycznych
- Recenzja 3.1A ;) w 6 gniazdach...
- Re: Recenzja 3.1A ;) w 6 gniazdach...
- Re: Recenzja 3.1A ;) w 6 gniazdach...
- Re: Recenzja 3.1A ;) w 6 gniazdach...
Najnowsze wątki
- 2025-07-23 Gdańsk => Programista Delphi <=
- 2025-07-23 Gdańsk => Programista Mainframe (z/OS, Assembler) <=
- 2025-07-23 Warszawa => Starszy inżynier DevOps (AWS) <=
- 2025-07-23 Gdańsk => Mainframe (z/OS, Assembler) Developer <=
- 2025-07-23 Kraków => Senior Fullstack Engineer (Low-Code Platform) <=
- 2025-07-23 Wrocław => Senior Key Account Manager IT <=
- 2025-07-23 Trójmiasto => Head of Social Media <=
- 2025-07-23 Rzeszów => Spedytor Międzynarodowy <=
- 2025-07-23 Lublin => ERP Implementation Consultant (AP Module) <=
- 2025-07-23 Środa Wielkopolska => SAP FI/CO Internal Consultant <=
- 2025-07-23 Warszawa => Inżynier oprogramowania .Net <=
- 2025-07-23 Kraków => Kotlin Developer <=
- 2025-07-23 Żerniki => Dyspozytor Międzynarodowy <=
- 2025-07-23 Warszawa => Java Developer <=
- 2025-07-23 Wrocław => Konsultant wdrożeniowy (systemy controlingowe) <=