From mboxrd@z Thu Jan 1 00:00:00 1970 From: presotto@plan9.bell-labs.com To: 9fans@cse.psu.edu Subject: Re: [9fans] sleep(), sched() and ilock() MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-hxbaipwqhdvpsobwvrhxhawbzu" Message-Id: <20001109211530.9CCDB199E4@mail.cse.psu.edu> Date: Thu, 9 Nov 2000 16:15:29 -0500 Topicbox-Message-UUID: 26bc0e7e-eac9-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-hxbaipwqhdvpsobwvrhxhawbzu Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit First. Am I right when supposing that the reason ilock() doesn't call scheduler is that it has to be sure that iunlock() executes on the same cpu? In general, if you are doing an ilock, it should be for something that can be done quickly. ilock is used when you're locking something that an interrupt routine also uses and scheding in the middle of it would be deadly. Second. Why doesn't sleep() simply call sched() right after it releases both locks? Am I unaware of some possible race condition? Off hand, I can't see any particular reason other than tunnel vision on our part. Looks like all we're doing is duplicating code with the net effect of saving 2 subroutine calls (splhi and sched). I may try it the other way and have Gerard Holtzman verify it again and see if I'm missing something myself. Third. It seems to me that sleep() might disable interrupts on a different cpu than is the one that enables them again before sleep() finishes. Is it ok when a process brings the old processor state to the new current processor and leaves the old one in (say) the splhi()'d state? Once you go frolicking through 'gotolabel(&m->sched)', the spl level is lost, i.e., schedinit always starts hi and returns low: any process coming out of a rescheduling comes out spllo(). That means that calling sched() when you are splhi() is wrong. This refers back to your first point. The processor that you did the sleep on will go spllo while its looking for a new process to run and will start that process up spllo. --upas-hxbaipwqhdvpsobwvrhxhawbzu Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Thu Nov 9 15:23:23 EST 2000 Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Thu Nov 9 15:23:22 EST 2000 Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.8.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 2D8C2199E9; Thu, 9 Nov 2000 15:23:10 -0500 (EST) Received: from alfa.comberg.cz (web.comberg.cz [212.24.142.98]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 46F0D199E3 for <9fans@cse.psu.edu>; Thu, 9 Nov 2000 15:22:02 -0500 (EST) Received: from beta (datela-1-4-120.dialup.vol.cz [212.20.98.154]) by alfa.comberg.cz (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA10857 for <9fans@cse.psu.edu>; Thu, 9 Nov 2000 21:38:51 +0100 Message-ID: <000501c022ac$54713b00$9a6214d4@cz99.cz> From: =?iso-8859-2?B?SmFrdWIgSmVybeH4?= To: "9fans" <9fans@cse.psu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [9fans] sleep(), sched() and ilock() Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0rc1 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Id: Fans of the O/S Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Wed, 20 Sep 2000 04:40:12 +0200 I am now reconsidering some aspects of sleeping, scheduling and ilocking that I considered clear. First. Am I right when supposing that the reason ilock() doesn't call scheduler is that it has to be sure that iunlock() executes on the same cpu? Second. Why doesn't sleep() simply call sched() right after it releases both locks? Am I unaware of some possible race condition? Third. It seems to me that sleep() might disable interrupts on a different cpu than is the one that enables them again before sleep() finishes. Is it ok when a process brings the old processor state to the new current processor and leaves the old one in (say) the splhi()'d state? Jakub Jermar --upas-hxbaipwqhdvpsobwvrhxhawbzu--