[boost] Re: shared_ptr/weak_ptr and thread-safety

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2003-05-23 03:46:57

< 2 x Forward Inline >

Joseph Seigh wrote:
[...]
> > >                                                    The one thing
> > > you usually cannot reliably observe in multi-threading is internal data
> > > state.  You have to use other mechanisms to define semantics for
> > > multi-threading.
> >
> > I don't think so.
> 
> I mean things like a method to get the reference count.  Not only
> does it expose an implementation dependent feature, but any post
> condition assertion based on that data is essentialy meaningless.

That's not true. You clearly need synchronization for any "post 
condition assertion", but ``that's it.''. And as for "data is 
essentially meaningless"... that's not true either; well, an 
illustration can be found here:

http://groups.google.com/groups?selm=3DE3A142.7DAACB3B%40web.de
(Subject: Re: threadsafe reference counting)

[...]
> > thread_safety::unsafe means that *copying* AND all mutation
> > operations on shared_ptr/weak_ptr copies (all pointing to the
> > same object; "typed-null" including) shall be *synchronized*;
> > otherwise, the behavior is undefined. Read-only stuff (copying
> > aside) can be done concurrently.
> >
> > thread_safety::basic means that all "const" operations
> > (including copying) can be done concurrently, but mutations
> > shall be synchronized; otherwise, the behavior is undefined.
> >
> > thread_safety::strong means "do-whatever-you-want-and-don't-
> > care-about-synchronization" (i.e. you can also mutate shared_ptr
> > and weak_ptr objects *concurrently* without any synchronization
> > because it's fully synchronized "internally").
> 
> I think you have some COW (copy on write) semantics leaking out
> there.  COW is internal implementation.  It should have no
> observable affect on external behavior which can be "thread-safe" or
> "thread-unsafe".  I.e., the behavior should be the same as a
> non COW object implementation.

There's no COW semantics here. It's rather simple, really. Any
operation that "updates" the use-count needs to be synchronized 
with respect to other readers/writers. The basic thread safety 
is pretty much the same stuff as POSIX's memory synchronization 
rules stated in 4.10/Base Definitions volume. Note that things 
like semas and pthread_refcount_t provide STRONG thread-safety
(for themselves; from "OO" point of view, if you look at their 
interface); well, with some "exceptions"... please take a look
at pthread_refcount_setvalue().

regards,
alexander.

**************************************************************

SenderX wrote:
[...]
> It seems that your reference counters provide portable barriers ( store,
> load )?

Yes. It provides the mutex-like acquire/release operations. This means
that BOTH software (compiler) AND hardware (MP) shall follow the rules
(constrain reordering of loads and stores). It's all in the spec. Why 
don't you simply read it and, perhaps, provide some USEFUL comments?

> 
> If so, your code is has to keep up with the hardware like lock-free algo's
> right?

Sort of. A "poor-man" (mutex-based; blocking) implementation can be 
found here:

http://www.terekhov.de/pthread_refcount_t/poor-man/beta2/prefcnt.h
http://www.terekhov.de/pthread_refcount_t/poor-man/beta2/prefcnt.c

> 
> If you can get portable membar & atomic ops #ifdef's for a lot of different
> processors, that would be cool... ;)

Yeah, that's for sure... http://tinyurl.com/cgyc

regards,
alexander.