PR 5432: Thread safety patches

Loren James Rittle
Wed Jan 23 09:22:00 GMT 2002

>> If
>>   template<typename _CharT, typename _Traits>
>>     basic_ostream<_CharT, _Traits>::sentry::
>>     sentry(basic_ostream<_CharT,_Traits>& __os)
>>     : _M_ok(__os.good()), _M_os(__os)
>>     {
>+       ::pthread_mutex_lock(&__os._M_mutex);
>!       if (this->_M_ok && __os.tie())
>> 	__os.tie()->flush();  
>>     }
>> is the sentry ctor, what did you have in mind?

> As above (given pthreads) and corresponding unlock in the destructor,
> and similarly for the other istream::sentry ctor/dtor.  I don't know 
> anything about other thread libraries, and precious little about 
> pthreads itself, but according to various man pages...:

Please do not reintroduce a direct pthread dependency into the library
implementation since we already took some pain to convert it to use
the gthr abstraction layer once already.  It is true that the gthr
abstraction layer does not provide the counting mutex (i.e. recursive
mutex) since not all threading layers support such.

If recursive action is required (and it appears so at first glance),
then I can build us a portable recursive mutex from the abstraction
provided by gthr.

> Sentry work is concerned with sharing particular iostream objects 
> among threads, where Craig's work is necessary to allow sharing the 
> iostream library itself among threads.  IOW, I think Craig's changes 
> are completely orthogonal to this work, fix a serious bug, and ought 
> to go in *immediately*.  Arguably it should go into 3.0.x too, if we've 
> advertised 3.0 as thread-safe-as-long-as-you-lock-shared-objects.

Fully agreed.
Loren J. Rittle
Senior Staff Software Engineer, Distributed Object Technology Lab
Networks and Infrastructure Research Lab (IL02/2240), Motorola Labs, KeyID: 2048/ADCE34A5, FDC0292446937F2A240BC07D42763672

More information about the Libstdc++ mailing list