From owner-freebsd-hackers Mon Nov 13 10:43:10 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 630F737B69E; Mon, 13 Nov 2000 10:43:02 -0800 (PST) Received: from laptop.baldwin.cx (john@dhcp245.osd.bsdi.com [204.216.28.245]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id eADIgjB57242; Mon, 13 Nov 2000 10:42:45 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Mon, 13 Nov 2000 10:43:11 -0800 (PST) From: John Baldwin To: Zhiui Zhang Subject: RE: simple lock and the lost wakeup problem Cc: freebsd-smp@FreeBSD.org, freebsd-hackers@FreeBSD.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 12-Nov-00 Zhiui Zhang wrote: > > I am new to SMP subject and have some questions to ask: > > Is the simplelock() really needed since FreeBSD is using the big giant > lock and the kernel is non preemptive? Or has FreeBSD changed the big > giant lock and made kernel thread preemptive? Uresha Vahalia talks about > Lost Wakeup Problem (page 196), the test of the resource and sleep() has > to be done atomically. Which correct mechanism should I use on FreeBSD to > achieve this (avoid the lost-wakeup problem)? simplelocks are used in interrupt handlers and a few other places that do not run while holding the big giant lock. In -current all of this has changed, however, as we now have mutexes. Most of the kernel is still under the Giant mutex at this point in time, but in the future Giant will be replaced by many other locks that protect data structures within the kernel. To avoid the lost wakeup problem I think you are referring to (I don't have Unix Internals here with me @ home) in -current, we have a replacment for tsleep() called msleep(). msleep() takes an additional parameter which is a mutex to release when going to sleep. From the kernel's perspective, the mutex is released and the process is put to sleep as an atomic operation. Hope this helps. > Any help is appreciated. > > -Zhihui > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message