No subject

       On  ``error checking'' mutexes, pthread_mutex_unlock actu­
       ally checks at  run-time  that  the  mutex  is  locked  on
       entrance,  and  that it was locked by the same thread that
       is now calling pthread_mutex_unlock.  If these  conditions
       are  not  met,  an  error  code  is returned and the mutex
       remains unchanged.   ``Fast''  and  ``recursive''  mutexes
       perform no such checks, thus allowing a locked mutex to be
       unlocked by a thread other than its owner.  This  is  non-
       portable behavior and must not be relied upon.

I'm inclined to say that it is an error to unlock a mutex that you
have not locked, and if you do so, the behavior is undefined.  This
is because on some platforms it is either expensive or impossible
at the API level to know whether the mutex has been locked by your
code.

I have modified the SDL headers to mention this.  Martin, can you
update the documentation?

Thanks!
	-Sam Lantinga, Software Engineer, Blizzard Entertainment