pthread_cond_signal() ambiguity

[Sad Clouds <cryintothebluesky%googlemail.com@localhost>]

As far as Pthreads standards go, calling pthread_cond_signal() and having the 
associated mutex unlocked is legal.

Below is what the standard says:

        "The pthread_cond_signal() or pthread_cond_broadcast() functions may be 
called by a thread whether or not it currently owns the mutex that threads 
calling pthread_cond_wait() or pthread_cond_timedwait() have associated with 
the condition variable during their waits; however, if predictable scheduling 
behaviour is required, then that mutex is locked by the thread calling 
pthread_cond_signal() or pthread_cond_broadcast()."

However reading NetBSD's man page, it suggests that having the mutex unlocked 
might produce undefined results:

        "The same mutex must be held while calling pthread_cond_broadcast() and 
pthread_cond_signal().  Neither function enforces this requirement, but if the 
mutex is not held the resulting behaviour is undefined."

Now my question is: does anyone think that NetBSD's implementation of 
pthread_cond_signal() is broken? I think quite a few people intentionally 
unlock the mutex before calling pthread_cond_signal(), so that the thread that 
wakes up can lock this mutex asap. and start running, instead of blocking.

Any comments?