This is the mail archive of the
pthreads-win32@sources.redhat.com
mailing list for the pthreas-win32 project.
RE: [pthread-win32] Re: pthreads on Win2k
- To: 'Tristan Savatier' <tristan at mpegtv dot com>, "Stephen R. Johns" <stephen dot johns at securelogix 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 16:33:20 -0500
- Cc: 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>
Here are some quotes from my multitude of books on PThreads:
1) Multithreaded Programming with PTHREADS, Bil Lewis & Daniel Berg, page 86
"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:
pthread_mutex_unlock
Errors:
[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 level
of error detection and reporting for some library calls. Although this
allows
vendors to design efficient library calls, it can pose a particular
problem
when you use mutex library calls.
In general, the Pthreads library reporta all errors associated with
resource
availability and system constraints on function operation. For example,
fi the
library realizes that it cannot initialize a mutex for a thread because
the
library itself hasn't enough space in its internal tables, it returns a
value
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
might
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 not
in its
default mode, see if it has a debug mode that provides additional error
detection."
Hope this helps,
John.
-----Original Message-----
From: Tristan Savatier [mailto:tristan@mpegtv.com]
Sent: March 23, 2001 3:58 PM
To: Stephen R. Johns
Cc: Steve Croall; 'John Funnell'; 'pthreads-win32@sourceware.cygnus.com'
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
threads..
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.
-t