From owner-cvs-all@FreeBSD.ORG Thu Jul 17 08:08:04 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91A2937B401; Thu, 17 Jul 2003 08:08:04 -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 42B9143FAF; Thu, 17 Jul 2003 08:08:03 -0700 (PDT) (envelope-from mtm@identd.net) Received: from kokeb.ambesa.net (dii5xaxbpqshoqd9@localhost [127.0.0.1]) id h6HF827k002479; Thu, 17 Jul 2003 11:08:02 -0400 (EDT) (envelope-from mtm@identd.net) Received: (from mtm@localhost) by kokeb.ambesa.net (8.12.9/8.12.9/Submit) id h6HF828d002478; Thu, 17 Jul 2003 11:08:02 -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 11:08:02 -0400 From: Mike Makonnen To: John Baldwin Message-ID: <20030717150802.GA2439@kokeb.ambesa.net> References: <200307171106.h6HB6emd076862@repoman.freebsd.org> <200307170911.43767.jhb@FreeBSD.org> <20030717145707.GA2205@kokeb.ambesa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030717145707.GA2205@kokeb.ambesa.net> 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-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2003 15:08:05 -0000 On Thu, Jul 17, 2003 at 10:57:07AM -0400, Mike Makonnen wrote: > On Thu, Jul 17, 2003 at 09:12:30AM -0400, John Baldwin wrote: > > > ... > > > 2. Once a umtx was contested all future locks and unlocks > > > were happening in the kernel, regardless of whether it > > > was contested or not. To prevent this from happening, > > > when a thread locks a umtx it checks the queue for that > > > umtx and unsets the contested bit if there are no other > > > threads waiting on it. Again, this is slightly more > > > complicated than it needs to be because we can't hold > > > a lock across casuptr(). So, the thread has to check > > > the queue again after unseting the bit, and reset the > > > contested bit if it finds that another thread has put > > > itself on the queue in the mean time. > > > ... > > > > The in-kernel mutexes handle this case during the unlock > > routine. When unlocking a contested mutex, if there is only > > one waiter, we wake up that waiter and set the lock cookie > > to MTX_UNOWNED without the contested bit set. If the woken > > thread is the only thread to try to acquire the lock, it > > suceeds and the lock remains uncontested until another thread > > blocks trying to lock it. This would mean that the next lock of > > the lock would not need to bounce into the kernel if the lock > > was not owned by anyone. > > 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? > In fact, now that I think about it, this race exists even now. So, I think your suggestion is needed regardless of where the unlock happens. 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!