Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 4 Feb 2008 12:18:37 +0100
From:      "Attilio Rao" <attilio@freebsd.org>
To:        "=?UTF-8?Q?Dag-Erling_Sm=C3=B8rgrav?=" <des@des.no>
Cc:        cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org, threads@freebsd.org
Subject:   Re: cvs commit: src/include pthread_np.h src/lib/libthr pthread.map src/lib/libthr/thread thr_mutex.c
Message-ID:  <3bbf2fe10802040318q456556e4g8c63299ab67c71e8@mail.gmail.com>
In-Reply-To: <86d4rdgehd.fsf@ds4.des.no>
References:  <200802032238.m13McAbf065324@repoman.freebsd.org> <86d4rdgehd.fsf@ds4.des.no>

next in thread | previous in thread | raw e-mail | index | archive | help

2008/2/4, Dag-Erling Smørgrav <des@des.no>:
> Dag-Erling Smorgrav <des@FreeBSD.org> writes:
>  >   Log:
>  >   Add pthread_mutex_islocked_np(), a cheap way to verify that a mutex is
>  >   locked.  This is intended primarily to support the userland equivalent
>  >   of the various *_ASSERT_LOCKED() macros we have in the kernel.
>
>
> I'm having second thoughts about this one.  There is a significant risk
>  of false positives if the mutex is currently locked by another thread.
>  I'm wondering whether to a) change the implementation so it only returns
>  true if the mutex is owned by the current thread, or b) change the
>  interface so you can specify a specific thread, or NULL for "any".

Please don't do the latter.
Semantically the right thing to do here is to assert if the curthread
owns the lock or not. Any lock should not be interested on what is the
state in regard of other locks.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein


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