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: "Bossom, John" <John dot Bossom at Cognos dot COM>
- Subject: Re: [pthread-win32] Re: pthreads on Win2k
- From: Ross Johnson <rpj at ise dot canberra dot edu dot au>
- Date: Sat, 24 Mar 2001 10:43:59 +1100
- 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>
- Organization: University of Canberra, DMT, xISE
- References: <430F887D415DD1118C2700805F31ECF104AFA33E@sota0005.cognos.com>
- Reply-To: rpj at ise dot canberra dot edu dot au
Hi all,
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
mutex
object ... to release it. A pthread_mutex_unlock() call by a
thread that is not the owner of the mutex results in undefined
behavior."
And under the heading "Errors":
"For each of the following conditions, if the condition is detected,
the
pthread_mutex_unlock() function shall return the corresponding error
number:
[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
other
"kinds" called PTHREAD_MUTEX_ERRORCHECK_NP and
PTHREAD_MUTEX_RECURSIVE_NP.
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:
http://www.opengroup.org/onlinepubs/7908799/xsh/pthread_mutexattr_gettype.html
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.
Regards.
Ross
"Bossom, John" wrote:
>
> 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