Re: Comments on the thread library

From: williamkempf_at_[hidden]
Date: 2001-04-03 16:53:44

--- In boost_at_y..., Lie-Quan Lee <llee1_at_l...> wrote:
> At Tue, 03 Apr 2001 21:08:31 -0000,
> William Kempf wrote:
> > >   "undefined" could be an alias of "guaranteed dead lock" 
depending 
> > > on the implementation in pthreads. 
> > 
> > No, undefined does _not_ mean "guaranteed dead lock" by the POSIX 
> > definition (so what specific implementations do is irrelevant).  
The 
> 
> Here is what IEEE-1003.1-200x says:
> If the mutex type is PTHREAD_MUTEX_DEFAULT, attempting to 
recursively
> lock the mutex results in undefined behavior.  Attempting to unlock
> the mutex if it was not locked by the calling thread results in
> undefined behavior. Attempting to unlock the mutex if it is not 
locked
> results in undefined behavior.
> 
> According to that, the pthread implementor is legal to make
> PTHREAD_MUTEX_DEFAULT type mutex to be an alias of
> PTHREAD_MUTEX_NORMAL type mutex which is "guaranteed dead lock" on
> recursive locking. 

Yes, but the policy remains "undefined".  They are still not 
synonyms, regardless of whether or not the implementation causes both 
to behave identically.

> I guess that my question in that message is: if does and should the
> "undefined" defined in Boost.Threads have different meaning than
> IEEE-1003.1-200x said?

It doesn't have a different meaning, and the two policies are quite 
different.  POSIX and Boost.Threads are in agreement here.

Bill Kempf