From owner-cvs-src@FreeBSD.ORG Thu Jul 17 10:02:48 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 36E6637B404 for ; Thu, 17 Jul 2003 10:02:48 -0700 (PDT) Received: from mail.speakeasy.net (mail10.speakeasy.net [216.254.0.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E31C43FAF for ; Thu, 17 Jul 2003 10:02:46 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 16428 invoked from network); 17 Jul 2003 17:02:45 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 17 Jul 2003 17:02:45 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h6HH2hGI026184; Thu, 17 Jul 2003 13:02:43 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20030717145707.GA2205@kokeb.ambesa.net> Date: Thu, 17 Jul 2003 13:02:58 -0400 (EDT) From: John Baldwin To: Mike Makonnen 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: Thu, 17 Jul 2003 17:02:48 -0000 On 17-Jul-2003 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? 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. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/