RE: destroying a locked mutex

RE: destroying a locked mutex

[Alexander Terekhov]

> The book, Programming with POSIX Threads indicates that
> pthread_mutex_destroy has the
> following return values:
>
> Errors:
>    [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:

RETURN VALUE

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
by mutex.

ERRORS

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.

also, fyi..

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.
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

regards,
alexander.


"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'" <scott@magruder.org>,
      pthreads-win32@sources.redhat.com
cc:
Subject:  RE: destroying a locked mutex




The book, Programming with POSIX Threads indicates that
pthread_mutex_destroy has the
following return values:

Errors:
     [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.

-----Original Message-----
From: Scott McCaskill [ mailto:scott@magruder.org ]
Sent: July 24, 2001 12:15 PM
To: pthreads-win32@sources.redhat.com
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).

RE: destroying a locked mutex

[Alexander Terekhov]

> Thank You  Alexander...

you are quite welcome

> I do not have the actual standard,
> only the popular books....

partially incomplete but "official"
volumes available here:

http://www.opengroup.org/onlinepubs/007908799/

i often use the latest draft -- "complete"
and includes rationale volume:

http://www.opengroup.org/austin/

regards,
alexander.

RE: destroying a locked mutex

[Bossom, John]

Thank You  Alexander... I do not have the actual standard,
only the popular books....

-----Original Message-----
From: Alexander Terekhov [ mailto:TEREKHOV@de.ibm.com ]
Sent: July 24, 2001 1:50 PM
To: Bossom, John
Cc: 'Scott McCaskill'; pthreads-win32@sources.redhat.com
Subject: RE: destroying a locked mutex




> The book, Programming with POSIX Threads indicates that
> pthread_mutex_destroy has the
> following return values:
>
> Errors:
>    [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:

RETURN VALUE

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
by mutex.

ERRORS

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.

also, fyi..

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.
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

regards,
alexander.


"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'" <scott@magruder.org>,
      pthreads-win32@sources.redhat.com
cc:
Subject:  RE: destroying a locked mutex




The book, Programming with POSIX Threads indicates that
pthread_mutex_destroy has the
following return values:

Errors:
     [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.

-----Original Message-----
From: Scott McCaskill [ mailto:scott@magruder.org ]
Sent: July 24, 2001 12:15 PM
To: pthreads-win32@sources.redhat.com
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).

RE: destroying a locked mutex

[Bossom, John]

The book, Programming with POSIX Threads indicates that
pthread_mutex_destroy has the
following return values:

Errors:
	[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.

-----Original Message-----
From: Scott McCaskill [ mailto:scott@magruder.org ]
Sent: July 24, 2001 12:15 PM
To: pthreads-win32@sources.redhat.com
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).

Re: destroying a locked mutex

[Alexander Terekhov]

> Should pthread_mutex_destroy() return an error if the mutex is locked?

POSIX standard says: "Attempting to destroy a locked mutex
results in undefined behavior."

in general, you should not destroy any object unless you
are absolutely sure that no one else is using it and/or
no reachable refs/ptrs to it is left somewhere around.

regards,
alexander.


"Scott McCaskill" <scott@magruder.org> on 07/24/2001 06:15:18 PM

Please respond to "Scott McCaskill" <scott@magruder.org>

To:   pthreads-win32@sources.redhat.com
cc:
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).

destroying a locked mutex

[Scott McCaskill]

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).