Re: Any interest in a weak pointer?

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-11 15:55:22

--- 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.

> > 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.

Bill Kempf