$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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