STL has no built in thread support, so you'll have to extend the STL
code with your own synchronization mechanisms to use STL in
a multithreaded environment. Case1 and Case2 are clearly
unsafe in my opinion. One of the troubles with thread programming
is things can appear to work correctly in development, but strange
bugs appear in the field when the execution environment can vary .
You need to apply very strict logical reasoning
in thread programming and be very conservative in your assumptions.
After that, test your code on a multiprocessor machine.
Case 1 - this is not thread safe, thread 1 may be preempted
while performing the insertion, leaving the map in an undefined state,
iteration over the map would be undefined. Inserting an element into
a map rearranges the internal arrangement of elements, so if this is
preempted
the internal arrangement may not be in a valid state.
You might want to look at the double-locking pattern which provides
a more efficient mechanism to deal with locking shared data structures.
Basically, a flag is set/reset to indicate a lock mutex lock is in place, if
the flag is set, then thread gives up and try again later, otherwise the
thread
proceeds to acquire the lock and set the flag. This attempts to avoid the
costly
operation of trying to acquire the lock and failing.
I'd have to look it up, but I think the map iterators would not be
invalidated, that
is an iterator would still "point" to the same element after an insertion,
just
that the internal links to its neighbours could be different, - again, if
the rearrangment
of the elements is preempted, imagine what chaos will result if you try to
iterate
over the elements...!
case 2 - again, this is unlikely to work, the push operation is non-atomic
so could be preempted mid-way, so you might have a situation where an
element has been inserted intot the queue but the count of elements hasn't
been updated...I in your example this is "harmless"situation, but I don't
think I'd like
to have it in my fly-by-wire navigation system
case 3 - I don't know - cout could be implemented to serialize the two
calls, but might not be for performance reasons with different
implementations.
dave
"Philip V Pham" <pv******@yahoo.com> wrote in message
news:Eg*****************@newssvr16.news.prodigy.co m...
These questions apply to std vector, map, and cout:
I am uncertain of the thread safety for reading/writing
for std templates. I know if all threads are reading
concurrently, it is thread safe. However, I have this situation:
Case 1: map
thread 1
---------
someMapOb [key] = value //inserting new pair
thread 2
---------
interator pos;
while (1==1)
{
for (pos = someMapOb.begin(); pos != someMapOb.end(), pos++ )
{
someValueOb = pos->second;
someValueOb.foo ();
}
sleep (1)
{
Is safe for case 1 if I do that? I don't care
if I miss a new inserted object in thread 2.
If a new object inserted into the map, will the
iterator be invalidated?
The reason that I omit a mutex is to maximize performance.
---------------
Case 2: queue
thread 1
--------
someQueue.push ( value );
thread 2
---------
while ( ! someQueue.isEmpty ()
{
// display a status indicator
// NOte, I don't pop or push the Q here
}
Is safe to call isEmpty() while the Q is being
pushed?
--------------------------
Case 3: cout
thread 1
--------
cout << "Thank you in advance for your help!" << endl;
thread 2
---------
cout << "Display....display ....." << endl;
I know the screen output might be messed up,
but would this concurrent cout cause a buffer overfloat
crash?
Thank you vey much for your help!
I look forward to hear from your solutions.