Re: [pthread-win32] Re: pthreads on Win2k

[Ross Johnson <rpj@ise.canberra.edu.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