This is the mail archive of the
mailing list for the pthreas-win32 project.
RE: [pthread-win32] Re: pthreads on Win2k
- To: "'rpj at ise dot canberra dot edu dot au'" <rpj at ise dot canberra dot edu dot au>, "Bossom, John" <John dot Bossom at Cognos dot COM>
- Subject: RE: [pthread-win32] Re: pthreads on Win2k
- From: "Bossom, John" <John dot Bossom at Cognos dot COM>
- Date: Fri, 23 Mar 2001 20:21:39 -0500
- Cc: 'Tristan Savatier' <tristan at mpegtv dot com>, "Stephen R. Johns" <stephen dot johns at securelogix dot com>, Steve Croall <SCroall at staffware dot com>, 'John Funnell' <jfunnell at projectmayo dot com>, "'pthreads-win32 at sourceware dot cygnus dot com'" <pthreads-win32 at sourceware dot cygnus dot com>
hmmm... Ross has more books than I!
From: Ross Johnson [mailto:firstname.lastname@example.org]
Sent: March 23, 2001 6:44 PM
To: Bossom, John
Cc: 'Tristan Savatier'; Stephen R. Johns; Steve Croall; 'John Funnell';
Subject: Re: [pthread-win32] Re: pthreads on Win2k
Re the use of mutex_unlock() by threads that don't own the mutex:
The standard says:
"The function pthread_mutex_unlock() is called by the owner of the
object ... to release it. A pthread_mutex_unlock() call by a
thread that is not the owner of the mutex results in undefined
And under the heading "Errors":
"For each of the following conditions, if the condition is detected,
pthread_mutex_unlock() function shall return the corresponding error
[EPERM] The current thread does not own the mutex."
The Linux pthread_mutex_unlock() manual page states:
"The pthread_mutex_unlock function returns the following
error code on error:
EINVAL the mutex has not been properly initialized.
EPERM the calling thread does not own the mutex
(``error checking'' mutexes only)."
Note the (``error checking'' mutexes only). The default type of mutex is
what it calls "fast", with no, or limited, error checking. There are two
"kinds" called PTHREAD_MUTEX_ERRORCHECK_NP and
See the manual page for pthread_mutexattr_setkind_np().
Other implementations appear to be based on the OpenGroup documentation
which is similar (Solaris, True64Unix), where again the default type
appears to be non-errorchecking, leaving it up to the programmer to
ensure sanity prevails. See:
We are currently working on adding the other mutex types as defined
in the OpenGroup pthread_mutexattr_settype() manual page, as well as
providing compatibility with Linux.
"Bossom, John" wrote:
> Here are some quotes from my multitude of books on PThreads:
> 1) Multithreaded Programming with PTHREADS, Bil Lewis & Daniel Berg, page
> "Because mutexes protect sections of code, it is not legal for
> one thread to lock a mutex and for another thread to unlock it.
> Depending upon the library implementation, this might not result
> in a runtime error, but it is illegal."
> 2) Programming with POSIX Threads, Butenhof, pg 319, describing the POSIX
> 1003.1c-1995 Interfaces:
> [EPERM} calling thread does not own mutex.
> 3) Pthreads Programming, Nichols:
> "Error Detection and Return Values", pg 68
> "The Pthreads standard allows implementations to define the exact
> of error detection and reporting for some library calls. Although this
> vendors to design efficient library calls, it can pose a particular
> when you use mutex library calls.
> In general, the Pthreads library reporta all errors associated with
> availability and system constraints on function operation. For
> fi the
> library realizes that it cannot initialize a mutex for a thread
> library itself hasn't enough space in its internal tables, it returns
> of EAGAIN or ENOMEM to the caller of pthread_mutex_init. However, the
> library does
> not have to detect improper uses of a mutex and report any errors that
> result. Such improper uses include:
> * Locking a mutex that you have not initialized
> * Locking a mutex that you already own
> * Unlocking a mutex that you don't own
> Hopefully, the library you use does detect these misuses. If it does
> in its
> default mode, see if it has a debug mode that provides additional
> Hope this helps,
> -----Original Message-----
> From: Tristan Savatier [mailto:email@example.com]
> Sent: March 23, 2001 3:58 PM
> To: Stephen R. Johns
> Cc: Steve Croall; 'John Funnell'; 'firstname.lastname@example.org'
> Subject: Re: [pthread-win32] Re: pthreads on Win2k
> Stephen R. Johns wrote:
> > Probably not related, but just in case...
> > I've been trying to port a linux program to pthreadw32, and found
> > a mutex issue/difference.
> > Linux allows threads other than the locking thread to unlock a mutex,
> > but pthreads does not.
> I don't recall that the POSIX standard places a restriction on
> which thread can unlock a mutex, but it does not look like good
> programming style to have a mutex locked and unlocked by different
> If posix-thread places a restriction that is not defined by the
> standard, it should be documented. It does not look like this
> one is a real problem... looks like POSIX should have put the
> restriction in the standard! I suppose that the underlying win32
> threads do have this restriction.