Re: Thread safe STL for VC6.0
"Stephen Howe" <stephenPOINThoweATtns-globalPOINTcom> wrote:
You _DONT_ want a threadsafe STL library.
Right, you want a thread-safe implementation of the C++ standardlibrary.
What I mean is that STL is something different than the C++
standardlibrary, and thread-safety is still important...
In itself, it is not good enough.
It operates at too fine a granularity to gain you anything. If you had
v.push_back(elem);
s = v.size();
while each operation push_back(), size() might be thread-safe, if you
needed both operations to be completed as a unit, STL's thread-safety
gains you _NOTHING_. An intervening thread could run between the two
operations. A mutex around both is what is needed. So if you require a
mutex to guarantee thread safety here, what has a thread-safe STL gained
you?
Wait: there are thread-safety guarantees that were made by e.g. the STL and
those are useful for the C++ standardlibrary, too. In particular that
concurrent read operations on an object don't interfere with each other is
an important point, and that is also guaranteed by any modern
implementation of the C++ stdlib (Note: I don't count the 10-year old one
that came with VC6 as modern).
Now, this thread-safety can only go so far, as you pointed out, I couldn't
read the main point from your example. I'd rather give a different example:
// If there is an element in the queue, handle that element
// now and then remove it from the queue.
if(!q.empty()) {
handle_element(q.front());
q.pop_front();
}
No possible implementation could make this work when there are concurrent
threads calling this code on the same queue. The reason is that 'empty()'
may itself run atomic but it can't guarantee that the queue is still
non-empty when executing the rest of the code. For that, indeed, you need
to guard access to the queue with a mutex or equivalent.
Uli
--
Sator Laser GmbH
Gesch??ftsf??hrer: Thorsten F??cking, Amtsgericht Hamburg HR B62 932