🚀 go-pugleaf

Seweryn Habdank-Wojewódzki wrote:

> Nie wiedzę o czym mówisz. W kodzie shared_ptr z boosta nie
> widzę żadnej synchronizacji, więc nie wiem o czym mówisz.

http://svn.boost.org/trac/boost/browser/trunk/boost/boost/detail/sp_counted_base_gcc_sparc.hpp?rev=34480

w szczególności treść funkcji compare_and_swap.

Ale problem jest znacznie poważniejszy: synchronizacja
odnosi się tylko do licznika, zmiany zawartości wskazywanego
przez obiektu nie są w żaden sposób synchronizowane
między procesorami. I teraz mi powiedz, ile programów
zawiera takie błędy. Na intelu będą działały bezawaryjnie,
na czymkolwiek innym (Sparc w trybie PSO i słabszym,
PowerPC, Itanium, Alpha) już nie i to w sposób skrajnie
niedeterministyczny.

To nie jest jednak problem boosta ani C++, bo model
spójności pamięci określa hardware. C++ nie rozwiązuje
go o tyle, że nie udostępnia jawnych barier (wystarczyłyby
semantyki acquire i release), a mógłby. _Niestety_ są
prowadzone prace nad opracowaniem modelu pamięci
w C++, który według mnie będzie dziełem napisanym
do szuflady, bo nie na poziomie języka leży problem.

Winą boosta jest tylko to, że daje użytkownikom złudzenie
bezpiecznego, wielowątkowego zliczania referencji i jeśli
ktoś nie słyszał o problematyce spójności, to biorąc to
narzędzie w dobrej wierze może się pokaleczyć. A sprawa
jest bardzo delikatna.

> A w ogóle pokaż mi te synchronizacje w kodzie boost::shared_ptr.

Sebastian dobrze Ci mówi, one tam _są_. A że nie wygląda jak muteks..?

> Np. systemy rozproszone najlepiej programują/projektują Ci co poczuli 
> gorzki
> smak C, C++ i innych języków brzydkich.

Coś w tym jest. Ale z drugiej strony zobacz sobie,
jak dziadki implementowały tablice w Algolu 68C:

http://birrell.org/andrew/papers/A68StorageManagement-Sigplan.pdf

i jak prymitywna przy tym jest oferta C++.

    Pozdrawiam
    Piotr Wyderski