🚀 go-pugleaf

Seweryn Habdank-Wojewódzki wrote:

>> w szczególności treść funkcji compare_and_swap.
>
> Ale u mnie np. operator= na następującą treść:
>
>    shared_ptr & operator=(shared_ptr const & r)
>    {
>        px = r.px;
>        pn = r.pn;
>        return *this;
>    }
>
> Nie widzę żadnej synchronizacji.

No ja się nie dziwię, że _nie widzisz_, bo jest ona ukryta w przeciążonym
operatorze =() środkowej instrukcji, operującej na klasie 
detail::shared_count:

    shared_count & operator= (shared_count const & r) // nothrow
    {
        sp_counted_base * tmp = r.pi_;

        if( tmp != pi_ )
        {
            if( tmp != 0 ) tmp->add_ref_copy();
            if( pi_ != 0 ) pi_->release();
            pi_ = tmp;
        }

        return *this;
    }

Zdradliwy języczek, co? :-)))

> Hmm... no to spełnia się moja teoria użyteczności Flame.

:-)

Mnie też się ona podoba. Wspominałeś coś ostatnio o teoretycznych
podstawach dobierania optymalnego predyktora do rozkładu danych,
chetnie bym się z tym bliżej zapoznał.

> A jak to jest w J, Py i reszcie bezpiecznego świata.

Aż tak szczegółowo nie znam tych platform.

> To jaki jest cel tego kodu.

Właśnie wielowątkowo bezpieczne zliczanie referencji. Ale
dokładnie TYLKO tyle. Na spójność zawartości dzielonych
w ten sposób obiektów żadnych gwarancji nie daje, bo i nie
może. Stąd poza szczególnym przypadkami, polegającymi
na ręcznym zapewnianiu spójności pamięci (czy to jawne
bariery, czy efekty uboczne tricków wyłączania forwardingu
itp. sztuczkek) boost::shared_ptr powinien być stosowany
tylko do obiektów const.

    Pozdrawiam
    Piotr Wyderski

PS. widzę, że poruszyliście sprawę włókien -- świetnie,
to bardzo ciekawy temat, ale zbliżone do moich wnioski
już zostały wyciągnięte, więc chwilowo nie mam nic do
dodania.