🚀 go-pugleaf

Sektor van Skijlen wrote:
> Oczywiście, że wiem. W przypadku mojej aplikacji jednak nie ma to akurat
> żadnego znaczenia - każda dana volatile ma swoje niezależne znaczenie i fakt,
> że jedna została dosynchronizowana, a druga nie, nie ma żadnego znaczenia. Że
> mi się pojawi aktualna wartość grubo po tym - mnie to wali. To zmienia tylko i
> wyłącznie relatywistyczne zależności czasowe między wątkami (wydaje się, że
> wuykonywały się w innych strefach czasowych, niż miało to faktycznie miejsce).
> 

To jak powiedział Maciek, to jest detal twojej aplikacji a nie ogólna 
tożsamość volatile z Javy i z C/C++.

[...]
>>Ponieważ w GCC volatile nie ma memory barrier to jeden procesor może widzieć 
>>zapisy w innej kolejności niż się faktycznie wydarzyły.
> 
> Super. A co MA memory barrier?

Choćby volatile z Javy :) A także volatile z MSVC 8.0

Przy czym typów barier jest wiele (zwykle uznaje się że 15 lub 16 lub nawet 
30). Bariera może blokować przenoszenie dostępów do pamięci ponad nią wstecz 
(czyli operacje "na zapas") i do przodu (czyli operacje "odkładane na 
później") i może dotyczyć operacji odczytu albo zapisu i te blokowania można 
ze sobą kombinować -- razem 15 typów barier. 16 typ (lub kolejne 15 typów) 
to bariera(y) kompilatora która dotyczy tylko reorganizacji dostępów do 
pamięci przez kompilator bez dotykania spraw procesora.

W GCC tą osytatnią to się robi przez volatile asm("", "", "");
Inne są machine specific i większość procesorów ma tylko niektóre kombinacje 
(co nie przeszkadza, bo zawsze można użyć silniejszej w miejscu słabszej) -- 
zwykle jest albo full barrier albo acquire (pełna blokada wsteczna), release 
(pełna blokada do przodu) barriers albo jedno i drugie. Każde zajęcie mutexa 
czy podobnego obiektu synchronizacyjnego zawiera conajmniej acquire a 
zwolnienie -- conajmniej release.

pzdr
\SK