Re: why boost:shared_ptr so slower?
On Aug 24, 4:26 pm, Keith H Duggar <dug...@alum.mit.edu> wrote:
On Aug 23, 2:25 pm, James Kanze <james.ka...@gmail.com> wrote:
[...]
Well for novice programmers it seems to mean something clear by
simple default of common sense language: if my use of it works
with a single thread then it works as-is with multiple threads.
In this context, I fear "clear and simple" is the equivalent of
"naive". As I said, I've seen code which carefully locks
internal accesses, then returns a reference to internal data. I
don't think we can base much on what "novice programmers" think
with regards to threading.
However, and I think we agree on this, it is a sign at least
that we should be a bit more careful that just claiming a class
is "thread-safe".
Totally agreed. I don't use the word in a positive sense in my
class documentation---I either specify a precise contract, or
state that it is not thread safe (which means that I don't make
any guarantees what so ever). On the other hand, we do need a
term for classes which can be used in multi-threaded
environments; i.e. which specify what you can and cannot do, and
what precautions you have to take. Boost::shared_ptr can
definitely be used in multithreaded environments, provided you
respect its contract---the implementation of std::string in g++
2.95.2 couldn't, because it didn't specify any contract (and
even something as simple as constructing a new string object
involved incrementing and decrementing a global counter).
[...]
Except that using precise terms helps to educate. So calling
it "conditionally thread-safe" would help to simultaneously
educate while just calling it "thread-safe" helps to introduce
bugs.
During the education process, you're obviously going to have to
define precisely what you mean by each term. And systematically
distinguishing between normal/basic thread safety and strong
thread safety might be a good idea---don't use "thread safety"
at all without a modifier.
Yes, I agree with that entirely and that really is the crux of
my point. And specifically one should not go around saying boost
shared_ptr is just plain unqualified "thread-safe".
It's partially a question of audience: it's generally clearer to
state something along the lines of "it defines a contract for
multithreaded use". But otherwise: what would you say that it
clear and concise to inform a potential user that it can be used
in a multi-threaded environment? ("Thread-aware" ?)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
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