From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <000501c022ac$54713b00$9a6214d4@cz99.cz>
From: =?iso-8859-2?B?SmFrdWIgSmVybeH4?= <jj@comberg.cz>
To: "9fans" <9fans@cse.psu.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: 7bit
Subject: [9fans] sleep(), sched() and ilock()
Date: Wed, 20 Sep 2000 04:40:12 +0200
Topicbox-Message-UUID: 26b29a06-eac9-11e9-9e20-41e7f4b1d025

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