From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Bossom, John" <John.Bossom@Cognos.COM>
To: 'Tristan Savatier' <tristan@mpegtv.com>, "Stephen R. Johns" <stephen.johns@securelogix.com>
Cc: Steve Croall <SCroall@staffware.com>, 'John Funnell' <jfunnell@projectmayo.com>, "'pthreads-win32@sourceware.cygnus.com'" <pthreads-win32@sourceware.cygnus.com>
Subject: RE: [pthread-win32] Re: pthreads on Win2k
Date: Fri, 23 Mar 2001 13:35:00 -0000
Message-id: <430F887D415DD1118C2700805F31ECF104AFA33E@sota0005.cognos.com>
X-SW-Source: 2001/msg00031.html

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