Re: [Boost-users] shared_ptr and weak_ptr concurrency

Subject: Re: [Boost-users] shared_ptr and weak_ptr concurrency
From: John Dlugosz (JDlugosz_at_[hidden])
Date: 2009-09-04 14:42:48

"undefined" means that anything at all could happen.  The computer might crash.
In real life, I expect worst to be that the readers gets inconsistent junk when reading p3, both because it is partly updated and because it might peek at the state more than once over time, with it still changing.

I agree that "just like built-in types" would not hold for the nonstandard implementation behavior of atomic reads and writes, so many people might misunderstand that.

I've had to implement smart-pointer like things that do have this feature, so it must be carefully designed to have only a single pointer in the main struct and update things to maintain a valid state at all times (e.g. swap in that main pointer last).  I don't suppose a standard-conforming shared_ptr would have that feature unless explicitly advertised as such.

> -----Original Message-----
> From: boost-users-bounces_at_[hidden] [mailto:boost-users-
> bounces_at_[hidden]] On Behalf Of Stefan Strasser
> Sent: Friday, September 04, 2009 1:29 PM
> To: boost-users_at_[hidden]
> Subject: Re: [Boost-users] shared_ptr and weak_ptr concurrency
> 
> Am Friday 04 September 2009 18:17:36 schrieb Chris Uzdavinis:
> > > the shared_ptr doc says that you can expect the same thread safety
> from
> > > shared_ptr as you can from built-in types.
> >
> > This is true, but you're drawing the wrong conclusion from it.
> > You need a lock around built-in types as well.  You need to use
> > an "atomic" type to safely do what you're saying.
> >
> > In the same documentation, they give examples which are
> > enlightening:
> >
> > //--- Example 3 ---
> >
> > // thread A
> > p = p3; // reads p3, writes p
> >
> > // thread B
> > p3.reset(); // writes p3; undefined, simultaneous read/write
> 
> I believe this means that the contents of p are undefined, not that
> there is
> an undefined state within a shared_ptr (on a platform that guarantees
> atomic
> pointers)
> 
> >
> > > you can use multiple-readers-single-writer without any locks on
> built-in
> > > types.
> >
> > Not true.  You can use multiple-readers, NO-writers without any
> locks,
> > however.
> 
> you can on platforms with atomic builtin types, as the c++ standard
> doesn't
> say anything about that (yet).
> 
> so if it is really true that that's not the case for shared_ptr, then
> the
> statement of the shared_ptr doc would be wrong. but as far as I can see
> from
> the shared_ptr implementation there is nothing that would indicate
> that.
> 
> could someone with more insight into the implementation clear this up
> please?
> (and maybe the documentation)
> 
> 
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users

TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.