Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 29 Nov 1998 17:27:58 -0500 (EST)
From:      Daniel Eischen <eischen@vigrid.com>
To:        eischen@vigrid.com, eivind@yes.no
Cc:        hackers@FreeBSD.ORG, jb@FreeBSD.ORG, lists@tar.com
Subject:   Re: Thread locking (was Re: cvs commit: src/include pthread.h src/lib/libc_r/uthread uthread_mattr_kind_np.c uthread_mutex.c)
Message-ID:  <199811292227.RAA02934@pcnet1.pcnet.com>

next in thread | raw e-mail | index | archive | help
Eivind Eklund wrote:
> On Sun, Nov 29, 1998 at 12:14:11PM -0500, Daniel Eischen wrote:
> > Isn't SS2 based off an earlier rev (draft) of the POSIX spec?
>
> No - it is AFAIK a superset of the POSIX standard.  It also require
> that if we detect the deadlock condition we should return EDEADLK -
> but we don't detect the case.  Allowing a lock to be "re-aquired" by
> the same thread just falls out of the code.

This falls into "undefined behaviour" which is allowed by POSIX
mutexes.  But one could interpret "undefined behaviour" as allowing
for an implementation that cannot check mutex ownership.  Since
we can easily check mutex ownership with the cost of a couple extra
instructions, we should do it.

> Another issue is that the standard isn't exactly internally consistent
> - it both require that a PTHREAD_MUTEX_NORMAL should deadlock if
> locked twice by the same thread, and that all deadlocks should return
> EDEADLK when detected.  You _could_ construct this as
> 'PTHREAD_MUTEX_NORMAL should not detect deadlocks", but detecting
> deadlocks is the only way we can make it deadlock (and I consider
> dictating that it shouldn't detect is too much dictation of internal
> details, anyway).

I'm glad you brought this up because I was kind of wondering why you
implemented a deadlock as an infinite loop.  Why not simply add
the mutex to the waiting threads queue and restrict unlocks on
PTHREAD_MUTEX_NORMAL to only the thread that owns the lock?  This
effectively deadlocks the thread because noone can ever unlock the
mutex.  Doing it this way, you don't have to "detect" a deadlock
condition ;-)

Dan Eischen
eischen@vigrid.com

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811292227.RAA02934>