Defect in XSH pthread_mutex_lock()

[yyyyyyyy@xxxxxxxxxx]

        Defect report from : Alexander Terekhov , IBM

(Please direct followup comments direct to yyyyyyyyyyyyyy@xxxxxxxxxxxxx)

@ page 1081 line 33962 section pthread_mutex_lock() comment 
{alt-EDEADLK-2003-02-24}

Problem:

Defect code :  3. Clarification required

This is in response the proposed action of the defect report 
"ud-mut1" which suggests the removal of the following non-
normative text from the pthread_mutex_lock()'s "RATIONALE" 
section:

<quote source=33978-33982>

For example, deadlocking on a double-lock is explicitly 
allowed behavior in order to avoid requiring more overhead 
in the basic mechanism than is absolutely necessary. (More 
"friendly" mutexes that detect deadlock or that allow 
multiple locking by the same thread are easily constructed 
by the user via the other mechanisms provided. For example, 
pthread_self() can be used to record mutex ownership.) 
Implementations might also choose to provide such extended 
features as options via special mutex attributes.

</quote>

It seems that the issue here is whether it would really be 
"friendly" [or rather: *conforming*; performance aside] for 
an implementation to provide a "circular wait dependency" 
deadlock detection feature "by default" [i.e. running a 
portable application that doesn't use any of non-standard
"special mutex attributes"].

IMO: yes and the EDEADLK error code may be used to report 
*any* deadlock condition -- things beyond a simple "double
lock" error too.

Action:

Change

  33962 [EDEADLK] The current thread already owns the mutex.

to

  33962 [EDEADLK] A deadlock condition was detected or the 
                  current thread already owns the mutex.

Please note that if accepted, this will probably require
making similar changes to other pthread blocking calls as 
well.