Re: Any interest in a weak pointer?

From: terekhov (terekhov_at_[hidden])
Date: 2002-01-14 03:53:41

--- In Boost-Users_at_y..., "bill_kempf" <williamkempf_at_h...> wrote:
> --- In Boost-Users_at_y..., "terekhov" <terekhov_at_d...> wrote:
> > --- In Boost-Users_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> > [...]
> > > I'm still not sure whether this is a shared_ptr problem... One 
> > might argue
> > > that the destructor of a mutable object is logically 
an "update" 
> and
> > > therefore should be mutex-protected as the rest of the 
operations 
> > on OBJ
> > > unless it's guaranteed to not compete with them.
> > 
> > http://groups.google.com/groups?as_umsgid=3BCAAB99.1157302E%
40web.de
> > 
> > "> If you need to access the object to clean it up before 
deleting 
> it,
> >  > you can lock it, to make sure you have the latest value. Do 
not 
> > assume
> >  > that just because the refcount is zero, you don't have to lock.
> > 
> >  Yeah, that would solve the visibility problem for 
> >  cleanup of mutable objects. However, with a lock 
> >  protecting more than one object we could still 
> >  block -- which would cause an unnecessary decrease 
> >  in concurrency, increased contention. Also, the 
> >  memory access reordering constrain (MBAR) injected 
> >  by unlock seems to be absolutely redundant to me 
> >  in this situation (and we would need unlock even 
> >  in the situation with a dedicated lock per object, 
> >  to ensure that lock destruction would not fail 
> >  with e.g. EBUSY, AFAIK)."
> > 
> > > On the other hand placing a memory barrier in shared_ptr will 
> > probably be a
> > > good thing from user point of view; 
> > 
> > I think so too, but how about portability...
> > also, given rather close to NULL amount of interest 
> > (wrt the proposal for having portable interface
> > specifically for ref.counting) I've observed on c.p.t, 
> > I am not sure at all... maybe I am missing something 
> > subtle and the whole idea of a single "RMB" might be 
> > a BS... I do not know, really.
> 
> I don't follow this paragraph at all.  Too many acronyms I can't 
> decipher.

BS == BULLSHIT ;-)

> > > but I don't want to make shared_ptr depend on pthreads.
> > 
> > Yeah, pthreads is not a boost library, but other than
> > that argument and perhaps some licensing issues wrt LGPL 
> > nature of pthreads-win32, I do not see why boosters just 
> > ignore pthreads. It is a standard and it is available on 
> > almost every platform out there (I mean basic threading 
> > stuff).
> 
> A) It's not available on every platform.
> B) It's a C library that fails to address several C++ issues.
> C) It has it's own issues with many of these topics, including 
memory 
> visibility.
> 
> A boost solution can't address all of the above concerns, but it 
can 
> come closer than POSIX and helps to define what's required when a 
> threading library is included in the C++ standard.

http://groups.google.com/groups?as_umsgid=3C33115D.E7EEC40%40web.de

regards,
alexander.