This is the mail archive of the
mailing list for the pthreas-win32 project.
RE: destroying a locked mutex
- To: 'Alexander Terekhov' <TEREKHOV at de dot ibm dot com>, "Bossom, John" <John dot Bossom at Cognos dot COM>
- Subject: RE: destroying a locked mutex
- From: "Bossom, John" <John dot Bossom at Cognos dot COM>
- Date: Tue, 24 Jul 2001 14:12:51 -0400
- Cc: 'Scott McCaskill' <scott at magruder dot org>, pthreads-win32 at sources dot redhat dot com
Thank You Alexander... I do not have the actual standard,
only the popular books....
From: Alexander Terekhov [mailto:TEREKHOV@de.ibm.com]
Sent: July 24, 2001 1:50 PM
To: Bossom, John
Cc: 'Scott McCaskill'; email@example.com
Subject: RE: destroying a locked mutex
> The book, Programming with POSIX Threads indicates that
> pthread_mutex_destroy has the
> following return values:
> [EBUSY] mutex is in use.
> [EINVAL] mutex is invalid.
that is true. however, these errors are made *optional*
because they are related to *undefined* behavior. you
should not rely on them. POSIX standard says:
The [EBUSY] and [EINVAL] error checks, **if implemented**,
act as if they were performed immediately at the beginning
of processing for the function and shall cause an error
return prior to modifying the state of the mutex specified
The pthread_mutex_destroy( ) function **may** fail if:
[EBUSY] The implementation has detected an attempt to
destroy the object referenced by mutex while
it is locked or referenced (for example, while
being used in a pthread_cond_timedwait() or
pthread_cond_wait()) by another thread.
Tradeoff Between Error Checks and Performance Supported
Many of the error checks were made optional in order to
let implementations trade off performance versus degree
of error checking according to the needs of their specific
applications and execution environment. As a general rule,
errors or conditions caused by the system (such as
insufficient memory) always need to be reported, but
errors due to an erroneously coded application (such as
**failing to provide adequate synchronization to prevent a
mutex from being deleted while in use) are made optional**.
A wide range of implementations is thus made possible.
For example, an implementation intended for application
debugging may implement all of the error checks, but an
implementation running a single, provably correct
application under very tight performance constraints in
an embedded computer might implement minimal checks. An
implementation might even be provided in two versions,
similar to the options that compilers provide: a full-
checking, but slower version; and a limited-checking,
but faster version. To forbid this optionality would
be a disservice to users.
By carefully limiting the use of ''undefined behavior''
only to things that an erroneous (badly coded) application
might do, and by defining that resource-not-available
errors are mandatory, this volume of IEEE Std 1003.1
ensures that a fully-conforming application is portable
across the full range of implementations, while not
forcing all implementations to add overhead to check for
numerous things that a correct program never does.
"Bossom, John" <John.Bossom@Cognos.COM> on 07/24/2001 07:04:14 PM
Please respond to "Bossom, John" <John.Bossom@Cognos.COM>
To: "'Scott McCaskill'" <firstname.lastname@example.org>,
Subject: RE: destroying a locked mutex
The book, Programming with POSIX Threads indicates that
pthread_mutex_destroy has the
following return values:
[EBUSY] mutex is in use.
[EINVAL] mutex is invalid.
Hint: Safets after unlocking mutex, when no other threads will lock.
Multithreaded Programmin with PThreads:
[EBUSY] Attempt to destroy a locked mutex.
From: Scott McCaskill [mailto:email@example.com]
Sent: July 24, 2001 12:15 PM
Subject: destroying a locked mutex
Should pthread_mutex_destroy() return an error if the mutex is locked?
pthreads-win32 seems to disagree with the linux implementation of pthreads
on this point (OK on windows, not on linux).