Date: Wed, 05 Mar 2003 11:56:39 -0500 (EST) From: John Baldwin <jhb@FreeBSD.org> To: Julian Elischer <julian@elischer.org> Cc: cvs-all@FreeBSD.org, cvs-src@FreeBSD.org, src-committers@FreeBSD.org, "Brian F. Feldman" <green@FreeBSD.org> Subject: Re: cvs commit: src/sys/kern kern_mutex.c Message-ID: <XFMail.20030305115639.jhb@FreeBSD.org> In-Reply-To: <Pine.BSF.4.21.0303041650310.42494-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 05-Mar-2003 Julian Elischer wrote:
>
>
> On Tue, 4 Mar 2003, Brian F. Feldman wrote:
>
>> John Baldwin <jhb@FreeBSD.org> wrote:
>> > already own. The mtx_trylock() will fail however. Enhance the comment
>> > at the top of the try lock function to explain this.
>> >
>> I admit I've never actually had a use for mtx_trylock() but... wouldn't you
>> like to detect it and assert against it if you're not expecting it? If
>> jlemon's behavior is the only one that relies on that part of the semantics,
>> perhaps it should be another kind of mtx_trylock() call. I guess the real
>> question is just whether or not the assert would ever have done good for
>> anyone while working.
>
>
>
> It's a bit late, but it seems a it !POLA to have mtx_try_lock() fail in
> a situation where mtx_lock() would succeed. ?
>
> I have used try_lock once, though I eventually did it anouther way.
>
> I have always thougth of try_lock as being
> "Try, but instead of sleeping, come back so I can try something else
> instead." The implicit message here is that if 'lock()'
> would succeed, try_lock() would succeed..
If you already own the lock, you should know that you already own the
lock in almost all cases, in which case you know you can safely call
mtx_lock() without blocking. mtx_lock() won't block on a lock you
already own.
> If you don't want this then maybe it should be called
> "try_lock_no_recurse()" or something..
> Or maybe the lock should be labled as non-recursive, so that
> the normal lock fails as well.
I can't retroactively label a lock non-recursive once trylock() is
called on it. :) Not without non-deterministic witness checking.
mtx_trylock() really should be used sparingly I think. I don't
want people doing this:
if (!mtx_trylock(foo))
tsleep(...);
If they want to block on a lock they should use mtx_lock(). Cases
where one might use mtx_trylock() that I can think of is for
optional optimizations for cases that might otherwise be a lock
order violation. I.e., if I can lock two X objects, then I can
bypass having to lock one, stick it on a queue so that some other
thread can connect it to the other. The only time I have used it
is in the OOM killer where I need to be able to lock a process I
am checking while keeping the current target process locked for
the whole loop. Really, I want the programmer to think carefully
when they use mtx_trylock() and blindly recursing on a lock might
result in some hard to track down bugs.
--
John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-src" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20030305115639.jhb>