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

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

[Bossom, John]

hmmm... Ross has more books than I!

-----Original Message-----
From: Ross Johnson [ mailto:rpj@ise.canberra.edu.au ]
Sent: March 23, 2001 6:44 PM
To: Bossom, John
Cc: 'Tristan Savatier'; Stephen R. Johns; Steve Croall; 'John Funnell';
'pthreads-win32@sourceware.cygnus.com'
Subject: Re: [pthread-win32] Re: pthreads on Win2k


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.ht
ml

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

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

[Ross Johnson]

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

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

[Bossom, John]

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

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

[Tristan Savatier]

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