"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@lists.boost.org [mailto:boost-users- bounces@lists.boost.org] On Behalf Of Stefan Strasser Sent: Friday, September 04, 2009 1:29 PM To: boost-users@lists.boost.org 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@lists.boost.org 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.