Date: Wed, 5 Mar 2003 11:40:30 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: John Baldwin <jhb@FreeBSD.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: <Pine.BSF.4.21.0303051134130.61509-100000@InterJet.elischer.org> In-Reply-To: <XFMail.20030305115639.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 5 Mar 2003, John Baldwin wrote:
>
> On 05-Mar-2003 Julian Elischer wrote:
> >
> >
> > On Tue, 4 Mar 2003, Brian F. Feldman wrote:
>
> 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.
>
The case I was using it for was basically:
if (!mtx_trylock(foo)) {
queue_data_for_later_proccessing(data)
return;
}
do_the_work_immediatly();
where it was possible that I had called myself as part of
do_the_work_immediatly() and wanted it to complete immediatly
since I knew I already owned the object.
I can see that in other cases you would want the alternative
behaviour however.
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?Pine.BSF.4.21.0303051134130.61509-100000>