HP aC++/HP C A.06.28 Programmer's Guide Integrity servers (769150-001, March 2014)

Limitations
In most cases, thread safety does not imply that the same object can be shared between threads.
In particular, when objects have user visible state, it would not make sense to share them between
threads. Consider the following:
void f(ostream &out, int x, int y) {
out << setw(3) << x << setw(10) << y;
}
This function would not be thread safe if called from multiple threads with the same object, since
the width in the shared object could be changed at any time. Therefore, such objects are not
protected from interactions between multiple threads, and the result of sharing such an object
between threads is undefined.
If the same object is shared between threads, a runtime crash, abort, or intermingled output may
occur. With the Rogue Wave Standard C++ Library 2.2.1, output may be intermingled but no
aborts will occur.
Using -D_THREAD_SAFE with the cfront Compatible libstream
There is an exception to the above rule for the cfront compatible libstream. For the frequently
used objects cout, cin, cerr, and clog, you can specify the -D_THREAD_SAFE compile time
flag for any file that includes <iostream.h>. In this case, a new instance of the object is
transparently created for each thread that uses it. All instances share the same file descriptor. The
f function in the above example will now work, because it receives one new out object per thread.
However, the results of two simultaneous executions of f will be mixed in any order in the output.
Using -D_THREAD_SAFE with the global scope operator is not supported for cout, cin, cerr,
and clog. For example, the following code would generate an error:
::cout << endl;
NOTE: If you use locks, you need not use the -D_THREAD_SAFE compile time flag since you
are now responsible for ensuring thread safety.
Differences between Standard iostreams and cfront Compatible libstream
The cfront compatible libstream supports locking for each insertion. Rogue Wave Standard C++
Library 1.2.1 and Tools.h++ 7.0.6 do not support locking but do provide a thread private buffer.
Visible differences would be as follows. In the case of standard iostreams, there is intermingling
of each component being inserted. With cfront compatible iostreams, there is intermingling of
complete buffers (depending on when endl or flush is called).
Using -D__HPACC_THREAD_SAFE_RB_TREE
The Rogue Wave Standard C++ Library 1.2.1 (libstd) and Tools.h++ 7.0.6 (librwtool) are
not thread safe if the underlying implementation rb_tree class is involved. In other words, if the
tree header file (which includes tree.cc) under /opt/aCC/include/ is used, these libraries
are not thread safe. Most likely, it is indirectly referenced by including the standard C++ library
container class map or set headers, or by including a RogueWave tools.h++ header like tvset.h,
tpmset.h, tpmset.h, tvset.h, tvmset.h, tvmset.h, tpmap.h, tpmmap.h, tpmmap.h,
tvmap.h, and tvmmap.h. Since changing the rb_tree implementation to make it thread safe
would break binary compatibility, the preprocessing macro, __HPACC_THREAD_SAFE_RB_TREE,
must be defined. The macro is automatically defined in the Itanium® based environment. A new
object file compiled with the macro defined should not be linked with older ones that were compiled
without the macro defined. Library providers whose library is built with the macro defined may
need to notify their users to also compile their source with the macro defined when the tree header
is included.
Using Threads 165