From owner-cvs-src@FreeBSD.ORG Thu Jul 17 20:24:33 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 029F437B415; Thu, 17 Jul 2003 20:24:31 -0700 (PDT) Received: from pool-151-200-10-97.res.east.verizon.net (pool-138-88-158-33.esr.east.verizon.net [138.88.158.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADF2143F85; Thu, 17 Jul 2003 20:24:29 -0700 (PDT) (envelope-from mtm@identd.net) Received: from kokeb.ambesa.net (2zkcwvyumzav1p41@localhost [127.0.0.1]) id h6I3OS7k006792; Thu, 17 Jul 2003 23:24:28 -0400 (EDT) (envelope-from mtm@identd.net) Received: (from mtm@localhost) by kokeb.ambesa.net (8.12.9/8.12.9/Submit) id h6I3OR9M006791; Thu, 17 Jul 2003 23:24:28 -0400 (EDT) (envelope-from mtm@identd.net) X-Authentication-Warning: kokeb.ambesa.net: mtm set sender to mtm@identd.net using -f Date: Thu, 17 Jul 2003 23:24:27 -0400 From: Mike Makonnen To: John Baldwin Message-ID: <20030718032426.GA6689@kokeb.ambesa.net> References: <20030717145707.GA2205@kokeb.ambesa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD/5.1-CURRENT (i386) cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_umtx.c src/sys/sys proc.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2003 03:24:33 -0000 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@identd.net | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon!