Re: why boost:shared_ptr so slower?
On Aug 21, 1:08 am, Keith H Duggar <dug...@alum.mit.edu> wrote:
On Aug 20, 5:56 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
Keith H Duggar wrote:
Boost shared_ptr is not "thread safe" by any standard that
is usually meant by the term:
First you claim that it's not thread-safe, and then you
point to the documentation which says that it is.
No, I pointed to a document that says it is "as thread safe as
..." not that it is "thread safe".
ie "the same level of thread safety as built-in types" means
not "thread safe".
You are confusing two different types of thread-safety.
No, you are fundamentally missing my point. Obviously I know
the level of "thread safety" that boost::smart_ptr provides
(since I posted the reference) so you should have at least
thought for a a moment about what my point is and at least
recognize the point (whether you agree or not) before
launching into an elaboration of what the document already
My point (since you missed it the first time) is that "as
thread safe as a built-in type" is not, in my opinion, what
one commonly thinks of when someone says a construct is
So what do you think one "commonly thinks of" when one says a
construct is "thread safe". As far as I can tell,
boost::smart_ptr meets the definitions of Posix, and offers
the maximum thread safety which one can reasonably expect.
So when you posted this
Naturally it should have the same basic properties:
it can easily be misunderstood or deceive someone without the
qualification "as a built-in type" which the boost document is
careful to include. To put it simply
"as thread-safe as a built-in type" != "thread safe"
In what way?
The basic definition of "thread safe", at least as I see it used
by the experts in the field, more or less corresponds to the
Posix definition: there is no problem using different instances
of the object in different threads, regardless of what you're
doing with them, there is no problem using the same instance in
different threads as long as none of the threads are modifying
the instance (from a logical point of view). Anything else
requires external synchronization. (I've not analysed
shared_ptr in detail, and it's possible that it doesn't meet
these guarantees. The implementation I have access to uses
__gnu_cxx::__atomic_add_dispatch, for example, and the last time
I looked, the implementation of that function could result in a
deadlock on 32 bit Sparcs under Solaris.)
James Kanze (GABI Software) email:firstname.lastname@example.org
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34