[Boost.smart_ptr] Thread Safety

Sorry, please ignore my previous post - finger trouble. The question is as follows: ------ Hi, Is shared_array completely thread-safe, including destruction/reference counting? From the code in /boost/detail/sp_counted_base_pt.hpp it looks like it probably is but according to http://www.boost.org/doc/libs/1_33_1/libs/smart_ptr/shared_ptr.htm#ThreadSaf... // thread A p3 = p2; // reads p2, writes p3 // thread B // p2 goes out of scope: undefined, the destructor is considered a "write access" shared_ptr isn't completely thread-safe for simultaneous read and write/destruct access? The same would presumbly apply to shared_array? Maybe I've missed something, are there compile-time configuration options to determine level of safety? Regards, T.

on Sat Jan 07 2012, "Thomas Jordan" <thomasjordan-AT-btinternet.com> wrote:
Sorry, please ignore my previous post - finger trouble. The question is as follows: ------
Hi, Is shared_array completely thread-safe, including destruction/reference counting? From the code in /boost/detail/sp_counted_base_pt.hpp it looks like it probably is but according to
http://www.boost.org/doc/libs/1_33_1/libs/smart_ptr/shared_ptr.htm#ThreadSaf...
I can't reach that (very ancient) page right now, but...
// thread A p3 = p2; // reads p2, writes p3
// thread B // p2 goes out of scope: undefined, the destructor is considered a "write access"
shared_ptr isn't completely thread-safe for simultaneous read and write/destruct access? The same would presumbly apply to shared_array? Maybe I've missed something, are there compile-time configuration options to determine level of safety?
shared_ptr<T> is almost exactly as threadsafe as T* is. In this case, thread A has a reference to an object on B's stack. That object is called p2. If thread A tries to use that object's value while the object is being destroyed, yeah, that's a race condition. The way to avoid this situation is for thread B to pass p2 to thread A by value, thus creating p2a, which thread A can read without concern. Now there's no race condition. Note: this change does /not/ cause the T object held by p2 to be copied. HTH, -- Dave Abrahams BoostPro Computing http://www.boostpro.com
participants (2)
-
Dave Abrahams
-
Thomas Jordan