The following has be reported by IBM LTC:  
RedHat EL3 Alpha 3: pthread_mutex_destroy() can destroy a locked mutex
Please fill in each of the sections below.

Hardware Environment:
2-way POWER3
Software Environment:
RedHat EL3 Alpha 3

Steps to Reproduce:
On Redhat EL3 Alpha 3, pthread_mutex_destroy() can successfully destroy a
mutex while it is locked.

The Linux man page of pthread_mutex_destroy() says:
   The pthread_mutex_destroy function returns the following error code  on
   error:
     EBUSY  the mutex is currently locked.

The IEEE Std 1003.1, 2003 (POSIX) standard specifies:
   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 ....

Test case and execution:
/home/xxue/work> cat destroymutex.c
#include <pthread.h>
#include <stdio.h>
#include <unistd.h>
#include <string.h>
pthread_mutex_t mymutex=PTHREAD_MUTEX_INITIALIZER;
int
main()
{
  int              rc;

  pthread_mutex_lock(&mymutex);
  rc = pthread_mutex_destroy(&mymutex);
  if (rc != 0)
  {
      printf("Error from pthread_mutex_destroy() <%s>.\n", strerror(rc));
  }
  else {
      printf("pthread_mutex_destroy() returns <%d>.\n", rc);
  }
}
/home/xxue/work> gcc destroymutex.c -lpthread
/home/xxue/work> a.out
pthread_mutex_destroy() returns <0>.

The same test case works as expected on other platforms, including SLES8:
/home/xxue/work> gcc destroymutex.c -lpthread
/home/xxue/work> a.out
Error from pthread_mutex_destroy() <Device or resource busy>.

1.
2.
3.

Actual Results:

Expected Results:

Additional Information:Mike - I know this is an alpha bug (against RHEL 3.0
Alpha), but I'd like to
ask if you can check the relevant POSIX standard for this issue before
we send it off to Red Hat.  Thanks.I found a thread of discussion about this on
a Red Hat-oriented message board, 
though none of the people in the thread are from Red Hat. Apparently this 
behaviour is undefined in POSIX and therefore optional. Error-checking of this 
nature is left otional to allow better performance in environments where the 
application can be trusted to be well-written.

Here is the link to the discussion:

http://sources.redhat.com/ml/pthreads-win32/2001/msg00065.html

Here is a link to a detailed discussion of pthread_mutex_destroy() on the Open 
Group site:

http://www.opengroup.org/onlinepubs/007904975/functions/pthread_mutex_destroy.ht
ml

It confirms this error-checking *may* be implemented, but it is optional (note 
the word *may* in Xing Xue's quote of the standard in the bug description 
above). *Shall* would be the word used for required implementation. This 
document references IEEE Std 1003.1, 2003 Edition, so we know this is current 
information.

I tried the test on RHAS 2.1 and it failed, so apparently this behaviour 
changed going from Linuxthreads in RHAS 2.1 to NPTL in RHEL Alpha 3. 

I verified the man page under RHAS 2.1 does indicate that this should return an 
error. If RHEL Alpha 3 is showing the same man page, perhaps the bug is that 
they have not updated the thread library man pages for NPTL.

But as far as this being a POSIX incompatibility, I recommend rejecting this 
bug as NOTABUG.
Given the POSIX standard says it "may" fail, I don't think we should rush
into the conclusion 'NOTABUG'.  I'd suggest to verify with Redhat
to see if this is the designed behavior of NPTL.Either NPTL is exibiting the
wrong behavior or Red Hat has not updated the man 
pages for RHEL Alpha 3 (more likely). In any case, a bug exists, so we will 
assign this bug to Red Hat.