Re: why boost:shared_ptr so slower?
On Aug 23, 3:18 am, Keith H Duggar <dug...@alum.mit.edu> wrote:
On Aug 22, 6:42 am, James Kanze <james.ka...@gmail.com> wrote:
On Aug 22, 3:23 am, Keith H Duggar <dug...@alum.mit.edu> wrote:
On Aug 21, 7:22 am, James Kanze <james.ka...@gmail.com> wrote:
On Aug 21, 1:08 am, Keith H Duggar <dug...@alum.mit.edu>
wrote: So what do you think one "commonly thinks of"
when one says a construct is "thread safe".
I mean that the entire type interface is "as thread-safe
as a POSIX-thread-safe function".
In other words (quoting the Posix standard): "A function
that may be safely invoked concurrently by multiple
threads." All of the member functions of boost::shared_ptr
meet that requirement.
[snip same old arguments ie that that some functions are only
safe when called on *different* objects and that it is this
conditional safety that "all the experts" mean when they say
"thread-safe"]
In other words, it is what N2410
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2410.html
proposed to call "strong thread-safe" also as Chris MT has
called in some other posts. However, note that since
"strong thread-safe" is simply the most natural extension
of POSIX "thread-safe" to C++ types, then "thread-safe"
without qualification should mean "strong thread-safe" and
that is consistent with your claim that "the experts in
the field, more or less corresponds to the Posix
definition". It's just I don't know where you got your
definition of POSIX "thread-safe" because that's not what
I recall from the POSIX document?
If you'd read the document you'd site, it points out quite
clearly that the so-called "strong thread-safety" is a very
na=E2=88=9A=C3=98ve meaning for thread safety.
It points out nothing about the notion being "naive". That is
your coloration. It simply points out the likely costs.
It doesn't use the word "naive", no. But that's a more or less
obvious interpretation of what it does say---that requiring the
"strong" guarantee is a more or less naive interpretation of
thread safety.
As pointed out above, Posix doesn't require it, and in fact,
no expert that I know defines thread-saftey in that way.
Finally, I will note N2519
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2519.html
which claims that the level of thread-safe that
boost::shared_ptr provides is "not widely recognized or named
in the literature" and that is consistent with my experience
as well.
It's curious that in the sentence immediately following this
statement, he cites a document that does "recognize" this
level of thread safety. And if this level of thread safety
has no special name, it's probably because it is what is
generally assumed by "thread-safety" by the experts in the
field; I've never seen any article by an expert in threading
that spoke of "strong thread-safety" other than to explain
that this is not what is meant by "thread-safety".
The crux of our disagreement is two fold 1) you hold that a
function can be "thread-safe" even if it conditionally imposes
some extra requirements such as different objects, buffer
pointers, etc 2) you hold that "all the experts" agree with
you.
As to 1) I simply disagree.
Then practically speaking, thread-safety is a more or less
useless term, except in a few special cases.
As I pointed out, my meaning is the one Posix uses, which is a
pretty good start for "accepted use" of a term.
I think something is "thread-safe" only if it is the naive
sense of "if the class works when there is only a
single-thread and is thread-safe, then it works when there are
multiple threads with *no additional synchronization coding
required* (note this was just a *toy* way of putting it, read
the article I'm about to link for a more useful wording and
discussion of it).
In other words, functions like localtime_r, which Posix
introduced precisely to offer a thread safe variant aren't
thread safe.
As to 2) well there are at least 3 experts who hold my view:
Brian Goetz, Joshua Bloch, and Chris Thomasson. Here is, an
article by Brian Goetz that lays out the issues very nicely:
http://www.ibm.com/developerworks/java/library/j-jtp09263.html
Except for Chris, I've never heard of any of them. But
admittedly, most of my information comes from experts in Posix
threading.
Finally, as to 1) ultimately it is a matter of definition. If
you are right and we all agree to call the "as thread-safe as
a built-in type" just "thread-safe" that would be fine too.
However, as you can see, there is disagreement and my point
here was simply that one should be a bit more careful that
just saying boost::shared_ptr is "thread-safe". Indeed, one
should call it exactly what the Boost document calls it "as
thread-safe as a built-in type" or perhaps "conditionally
thread-safe" so as to be careful and avoid confusion.
It's always worth being more precise, and I agree that when the
standard defines certain functions or objects as "thread-safe",
it should very precisely define what it means by the term---in
the end, it's an expression which in itself doesn't mean much.
Formally speaking, no object or function is required to meet its
contract unless the client code also fulfills its obligations;
formally speaking, an object or function is "thread safe" if it
defines its contractual behavior in a multithreaded environment,
and states what it requires of the client code in such an
environment. Practically speaking, I think that this would
really be the most useful definition of thread-safe as well, but
I think I'm about the only person who sees it that way. The
fact remains, however, that Posix and others do define
thread-safety in a more or less useful form, which is much less
strict than what you seem to be claiming.
And by the way, that last point is not just some pointless
nit- pick. Even in the last year-and-half at work, I caught
(during review) three cases of thread-unsafe code that was a
result of a boost::shared_ptr instance being shared unsafely
(all were cases of one thread writing and one reading). When I
discussed the review with the coders all three said exactly
the same thing "But I thought boost::shared_ptr was
thread-safe?". Posts like Juha's that say unconditionally
"boost::shared_ptr is thread-safe" continue to help perpetuate
this common (as naive as you might say it is)
misunderstanding.
OK. I can understand your problem, but I don't think that the
problem is with boost::shared_ptr (or even with calling it
thread-safe); the problem is education. In my experience, the
vast majority of programmers don't understand threading issues
in general: I've seen more than a few cases of people putting
locks in functions like std::vector<>::operator[], which return
references, and claiming the strong thread-safe guarantee. Most
of the time, when I hear people equating strong thread-safety
with thread-safety in general, they are more or less at about
this level---and the word naive really does apply. Just telling
them that boost::shared_ptr is not thread safe in this sense is
treating the symptom, not the problem, and will cause problems
further down the road. (Again, IMHO, the best solution would be
to teach them that "thread-safety" means that the class has
documented its requirements with regards to threading somewhere,
and that client code has to respect those requirements, but I
fear that that's a loosing battle.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=C3=A9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=C3=A9mard, 78210 St.-Cyr-l'=C3=89cole, France, +33 (0)1 30 23 00 =
34