STL problem

[hunter tang]

Hi,

In STL 1.2.1, I'm use deque as the message queue, the producer use "push_back()" call, and the cosumer use "front()" and "pop_front()" calls, it seems a mutex_lock is a must for multi thread situation, even if I added command line "-DRWSTD_MULTI_THREAD, -D_REENTRANT, -D_THREAD_SAFE"
If I remove the mutex_lock for "push-back()" and "front(), pop_front()" there will be sth. wrong.

Does anyone know if these options work for thread safety?
Does any other call exist for stl that can read and remove one element from deque in one function? maybe in that i need not use the mutex_lock.

Thanks in advance

hunter

[Adam J Markiewicz]

Hi

Deque is just a structure to hold the data. If you want to use it from several threads you have to ensure proper synchronisation. Doing it with mutex is a good choice. Your defines look fine also.

However be carefull with front(), as it does not remove the object, so the WHOLE TIME OF ACCESSING to the object should be protected with mutex. Have a look (this is not a real code, but more like the idea):

mutex_lock();
object &o = deque.front();
mutex_unlock();

object.do_something(); // WRONG!!!!

After mutex is unlocked some other thread can get the access to it at the same time. As result terrible and absolutelly unpredictable things may happen (and will happen after some time of usage).

Good luck
Adam

[hunter tang]

Thanks Adam for your response.

I want to remove these mutex_locks because when I use caliper "sample_ip" to run the program, I see much of the time spending on mutex_locks. So there is no working around?

And, what do you know about the thread safety of STL on HPUX now?

Rgds
hunter

[Mike Stroyan]

You could try to reduce the number of mutex operations. If there is only on consumer, then
it could remove multiple objects from the queue within one locked interval. It could move those to a thread-specific queue.


You should use caliper cgprof to confirm which functions are making frequent calls to the mutex_locks. You might be surprised and find that they are happening in other places as well.

[hunter tang]

Thanks

I'm sure the mutex_lock is mainly in this code sections, and I can't get several elements at one read.


I'm still curious about if there is any way to read and delete an element from a deque(or queue) in one function call. And If the STL thread safe are verified.

rgds
hunter

[William Wong_2 · Accepted solution]

If you are using the STL with HP aC++ then it is not thread safe.

Q: Are HP aC++ libraries thread-safe?
A: In general, HP aC++ libraries are coded to be thread-safe. On HP-UX 10.10 and 10.20, they use mutexes to protect library global data using user-threads (libcma). On HP-UX 11.00 and beyond they use kernel threads (libpthread). Refer to the HP aC++ Online Programmer's Guide for a list of required compile and link time options.

However, the Rogue Wave Standard C++ Library version 1.2.1 (libstd) provided with HP aC++ is not thread-safe. A problem when using threads with Rogue Wave STL containers was discovered and reported in "C++ Report" of July/August 1998, Volume 10, Number 7. The article is titled "STL Implementations and Thread Safety" by Sergey Ignatchenko.

For example, the implementation of a set of ints, set contains a template static data member shared among all objects. No thread synchronization is done on this member and operations on one object in one thread may corrupt another object in another thread.

To insure thread safety for rb_tree class objects, use the -D__HPACC_THREAD_SAFE_RB_TREE option on both the compile and link lines. Only HP aC++ version A.01.21 and subsequent versions incorporate this option. Note that code compiled with this option is binary incompatible with code that is not compiled with this option. Refer to the Threads section of the HP aC++ Online Programmer's Guide for more detail.

[hunter tang]

Thanks William,

The platform is HPUX 11.22 on rx5670. So the doc you mentioned is this:
http://docs.hp.com/hpux/onlinedocs/1559/threads.htm

It seems I have to use mutex_locks here.

rgds
hunter