Re: why boost:shared_ptr so slower?
"Juha Nieminen" <nospam@thanks.invalid> wrote in message
news:Hiyjm.60$lD3.31@read4.inet.fi...
Chris M. Thomasson wrote:
FWIW, Boost shared_ptr only provides basic/normal thread-safety. It does
NOT provide strong thread-safety in any way shape or form.
I don't even understand the difference between "basic/normal" and
"strong".
Please read here:
http://www.boost.org/doc/libs/1_39_0/libs/smart_ptr/shared_ptr.htm#ThreadSafety
Please take note of the first word in the following sentence:
"Different shared_ptr instances can be "written to" (accessed using mutable
operations such as operator= or reset) simultaneously by multiple threads
(even when these instances are copies, and share the same reference count
underneath.)"
See? The SAME instance of a shared pointer CANNOT be written to by multiple
threads. The same instance of a shared pointer cannot be written to by
thread A, and simultaneously read from by thread B. This describes
limitation of basic/normal thread-safety level. On the other hand, this is
perfectly legal with a strong thread-safety level.
Take note of example 5:
//--- Example 5 ---
// thread A
p3.reset(new int(1));
// thread B
p3.reset(new int(2)); // undefined, multiple writes
If shared_ptr was strongly thread-safe, then example 5 works fine. In fact,
if it honored strong thread-safety, then examples 3-5 would also work fine.
I dare you to try and get the following example pseudo-code to work without
using mutual exclusion:
_______________________________________________________________
static shared_ptr<foo> global_foo;
void writer_threads() {
for (;;) {
shared_ptr<foo> local_foo(new foo);
global_foo = local_foo;
}
}
void reader_threads() {
for (;;) {
shared_ptr<foo> local_foo(global_foo);
local_foo->read_only_operation()();
}
}
_______________________________________________________________
boost::shared_ptr is thread-safe because instance of it can be used in
different threads even if these instances point to the same object.
boost::shared_ptr doesn't malfunction if two threads manipulate these
instances at the same time.
NO! See, a single instance of boost::shared_ptr CANNOT be simultaneously
written to (e.g., operator = or reset()) by more than one thread. A single
instance of boost::shared_ptr CANNOT be written to and read from by more
than one thread simultaneously. This is due tot he fact that shared_ptr is
not strongly thread-safe.
You seem to be talking about thread-safety of the shared object
itself, rather than the thread-safety of boost::shared_ptr.
I am not writing about that in any way, shape or form.
That's a completely different issue.
Agreed.
Whether the shared object is thread-safe is,
of course, up to the object. Why should boost::shared_ptr have anything
to do with that?
It should not have anything to do with that; period.
That's exactly as silly as saying that if the shared
object contains a pointer to dynamically allocated memory, it's
boost::shared_ptr's duty to free that memory as well, rather than the
object's duty.
Agreed, that would be silly!