a warning on using SGI STL in a multi-threaded (omniORB) environment

[Gary D. Duzan]

In Message <199802191119.LAA09528@santaka.cam-orl.co.uk> ,
   Sai-Lai Lo <S.Lo@orl.co.uk> wrote:

=>Here you go, Sai Lai:
=>
=>	Potential bug warning : When using the pthreads package (as with
=>omniORB2), in conjunction with the SGI Standard Template Library
=>implementation, it is important to set the _PTHREADS define, to ensure
=>correct concurrency control.  Failing to do so will not result in adverse
=>affects on most systems but can cause data corruption on multiprocessor
=>systems, if threads are accessing different STL structures concurrently.
=>
=>	I think that summarises the problem.
=>
=>James "Wez" Weatherall

   I noticed this in my recent thread-safeness crusade as well. Note
that "STLport" (http://www.metabyte.com/~fbp/stl/effort.html) is based
on SGI's STL, so _PTHREADS should be set for it as well.
   Of particular interest with regards to a library's thread-safeness
is memory allocation. For example, the USL/SC library uses a Pool class
to allocate memory for String, List, Map, etc. But since Pool is not
thread- safe, you can't even mutex a particular instance of one of
these classes since the very act of allocating space for it could cause
corruption. It would be rather annoying if creating a List corrupted a
completely unrelated String. So whenever possible, check to make sure
that any libraries you are using are thread-safe. If they aren't,
either you have to fix them so that they are or try keeping all use of
the library to a single thread. This include system libraries, like X.
As I understand it, if you have X11R6 and Motif 2.X libraries, they are
thread-safe, but X11R5 and Motif 1.X are not.
   Threads are great when everyone uses them. Otherwise they can be a
pain.

					Gary Duzan
					GTE Laboratories