Path: utzoo!dciem!nrcaer!sce!graham
From: graham@sce.carleton.ca (Doug Graham)
Newsgroups: comp.os.minix
Subject: Re: FS (was: Re: Assorted questions)
Message-ID: <883@sce.carleton.ca>
Date: 23 Jul 90 04:36:43 GMT
References: <628@philica.ica.philips.nl> <1685@tuvie> <633@philica.ica.philips.nl> <2013@runxtsa.runx.oz.au>
Organization: Carleton Univerity, Ottawa, Canada
Lines: 41

In article <2013@runxtsa.runx.oz.au> brucee@runxtsa.runx.oz.au (Bruce Evans) writes:
>
>Switching *from* a thread can easily be handled in rw_dev (note all physical
>i/o goes through there):
>
>	while (waiting_for_reply_from(task_nr)
>	    || (r = send(task_nr, mess_ptr)) == E_LOCKED)
>		/* Don't send if FS is sure to block. Try later if the send
>		 * failed due to deadlock prevention.
>		 */
>		unready_current_thread_and_run_another();
>	if (r != OK) panic("blah", r);
>	unready_current_thread_and_run_another();
>
>This assumes a dispatcher thread that is always ready to run. It just loops
>waiting for replies. When one arrives, it readies the thread that sent the
>corresponding request and any others in the wait loop with task_nr ==
>replying_task_nr, and picks one to run.

If FS must be left as a task, or pool of tasks, this is probably the best way
to go. But I think you mispelled the name of the call that switches between
threads. Rather than "unready_current_task_and_run_another()", it should be
"sleep(task_nr)". The call that the dispatcher thread makes is
"wakeup(task_nr)". :-) In any case, it sounds like you're proposing a
synchronization mechanism that goes beyond message passing. Is this the case,
or would you implement these new "primitives" via message passing in some way?

I don't think it's this simple though. I mentioned in an earlier
message, that it's quite possible that two user processes, and thus two
FS threads, may be trying to read the same disk block. In this case,
I don't think the second request should get as far as rw_dev. Higher
level software would have to notice that the disk block was already
being read in, and block the second thread until the disk block became
available. Inodes and things would need to be locked as well. If this is
not done, an FS thread that blocked for one reason or another, would
not be able to make any assumptions about the state of the system after
returning from the blocked state. It might be possible to write FS
like that, but it sure would be difficult.

----
Doug.