Re: What's the connection between objects and threads?
On May 24, 6:55 pm, Gerhard Fiedler <geli...@gmail.com> wrote:
On 2008-05-21 05:47:37, James Kanze wrote:
SGI statement simply contradicts you: "If multiple threads
access a single container, and at least one thread may
potentially write, then THE USER IS RESPONSIBLE FOR
ENSURING MUTUAL EXCLUSION BETWEEN THE THREADS during the
container accesses." It is just safe for reading, so what I
said was correct that it is thread safe to a certain
extent.
That's not the only guarantee it gives. It specifies the
contract that you have to respect. In other words, it is
completely thread safe.
Using Wikipedia as one of the repositories that reflect
"common use",
Common use by whom? The Wikipedia isn't exactly what I would
call a reference.
it seems that there is at least one use of "thread safety"
that contradicts you.
There are a lot of people who seem to think that "thread safety"
means that the programmer doesn't have to do anything, and that
everything will just magically work. Such thread safety doesn't
exist in the real world, however; such a definition is useless;
and I don't know of any competent person who would use it.
From <http://en.wikipedia.org/wiki/Thread-safe>: "A piece of
code is thread-safe if it functions correctly during
simultaneous execution by multiple threads."
Which is rather ambiguous. What is meant by "simultaneous
execution"? The code in the allocators of an STL vector cannot
normally be executed simultaneously by multiple threads, but
certainly you wouldn't consider STL vector to not be thread safe
because it uses some sort of protection interally to ensure that
it doesn't execute simultaneously. And if you follow the rules
laid down by SGI (which are basically those of Posix), all of
the functions in their implementation work in a multithreaded
environment. (Roughly speaking, SGI uses the same definition as
Posix. Except that I don't think that any of the functions in
their implementation of the library are not thread safe, where
as in Posix, things like localtime, etc. are not thread safe.)
Most STL implementations need additional implementation
elements, usually what the same article refers to as "mutual
exclusion", to achieve this goal -- which makes them not
thread safe in the sense of this article.
If that's what the article actually says, then it's off base.
One can talk of different degrees of thread safety (although I
don't like the expression), with different types of guarantees,
but when you say that a function is not thread-safe, at all, you
mean something like localtime, which isn't thread safe and
cannot be used at all in a multithreaded environment. And if
you call the SGI implementation of std::vector "not
thread-safe", what do you call something like localtime?
--
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