Date: Thu, 17 Jul 2003 09:12:30 -0400 From: John Baldwin <jhb@FreeBSD.org> To: Mike Makonnen <mtm@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_umtx.c src/sys/sys proc.h Message-ID: <200307170911.43767.jhb@FreeBSD.org> In-Reply-To: <200307171106.h6HB6emd076862@repoman.freebsd.org> References: <200307171106.h6HB6emd076862@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 17 July 2003 07:06 am, Mike Makonnen wrote: > mtm 2003/07/17 04:06:40 PDT > > FreeBSD src repository > > Modified files: > sys/kern kern_umtx.c > sys/sys proc.h > Log: > Fix umtx locking, for libthr, in the kernel. > ... > 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. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200307170911.43767.jhb>