svn commit: r302194 - head/lib/libthr/thread

[Jilles Tjoelker]

On Sat, Jun 25, 2016 at 11:30:40AM +0000, Konstantin Belousov wrote:
> Author: kib
> Date: Sat Jun 25 11:30:40 2016
> New Revision: 302194
> URL: https://svnweb.freebsd.org/changeset/base/302194

> Log:
>   For pthread_mutex_trylock() call on owned error-check or non-portable
>   adaptive mutex, return EDEADLK as required by POSIX.  The
>   pthread_mutex_lock() is already compliant.

>   Tested by:	Guy Yur <guyyur at gmail.com>
>   Sponsored by:	The FreeBSD Foundation
>   MFC after:	2 weeks
>   Approved by:	re (gjb)

> Modified:
>   head/lib/libthr/thread/thr_mutex.c

> Modified: head/lib/libthr/thread/thr_mutex.c
> ==============================================================================
> --- head/lib/libthr/thread/thr_mutex.c	Sat Jun 25 10:08:04 2016	(r302193)
> +++ head/lib/libthr/thread/thr_mutex.c	Sat Jun 25 11:30:40 2016	(r302194)
> @@ -850,9 +850,12 @@ mutex_self_trylock(struct pthread_mutex 
>  
>  	switch (PMUTEX_TYPE(m->m_flags)) {
>  	case PTHREAD_MUTEX_ERRORCHECK:
> -	case PTHREAD_MUTEX_NORMAL:
>  	case PTHREAD_MUTEX_ADAPTIVE_NP:
> -		ret = EBUSY; 
> +		ret = EDEADLK;
> +		break;
> +
> +	case PTHREAD_MUTEX_NORMAL:
> +		ret = EBUSY;
>  		break;
>  
>  	case PTHREAD_MUTEX_RECURSIVE:

I think POSIX (SUSv4tc1, XSH 3 pthread_mutex_lock) is clear that only
pthread_mutex_lock() can fail with [EDEADLK], not
pthread_mutex_trylock(). Instead, the error [EBUSY] listed for
pthread_mutex_trylock() applies whenever the mutex could not be acquired
because it was already locked. This includes the case where the mutex is
owned by the current thread. Note that POSIX intends to allow not
storing the owning thread's ID in non-recursive non-robust mutexes.

Failing pthread_mutex_trylock() on owned mutexes only with [EBUSY] also
matches our code before this commit and NetBSD's code, and is apparently
expected by other code.

Therefore, I think this commit should be reverted.

-- 
Jilles Tjoelker