cvs commit: src/sys/kern kern_umtx.c src/sys/sys proc.h

[Mike Makonnen]

On Thu, Jul 17, 2003 at 01:02:58PM -0400, John Baldwin wrote:
> 
> > Initially I was going to do it this way. But there were a couple of
> > things that concerned me so I thought it would be safer to implement
> > it the way I did. One of them is that it opens up a race between a
> > thread that is trying to acquire the umtx for the first time, and the
> > thread that the unlocker just woke up. I suppose we could introduce
> > a UMTX_RESERVED or something (UMTX_UNOWNED is already used) that no
> > one except a thread that just woke up could lock. Is that what you
> > are suggesting?
> 
> There is no race there.  If both threads want the lock, one will
> suceed and the other will block on it and have to mark the lock as
> contested.  This is how that works with the kernel mutexes.  This
> does mean that you need to loop in the umtx_lock() function in the
> kernel and that you need to allow for the fact that you may be
> trying to acquire an uncontested, unowned mutex.

Ahh ok, the current code is fine then (it takes care of the looping,
etc).
I was under the impression that locks were a first-come first-served
deal. Otherwise, there's the unlikely-but-not-zero possibility of thread
starvation. But, this may be a misconception on my part. In anycase,
I'll take your suggestion and move the unseting into the unlock code.
I may end up having to revise everything when I fix mutex
priorities, but I'll cross that bridge when I get to it.

Cheers.
-- 
Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
mtm at identd.net | D228 1A6F C64E 120A A1C9  A3AA DAE1 E2AF DBCC 68B9
mtm at FreeBSD.Org| FreeBSD - Unleash the Daemon!