Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!samsung!munnari.oz.au!metro!ipso!runxtsa!brucee
From: brucee@runxtsa.runx.oz.au (Bruce Evans)
Newsgroups: comp.os.minix
Subject: Re: FS (was: Re: Assorted questions)
Message-ID: <2013@runxtsa.runx.oz.au>
Date: 20 Jul 90 22:46:41 GMT
References: <628@philica.ica.philips.nl> <1685@tuvie> <633@philica.ica.philips.nl>
Organization: RUNX Unix Timeshare.  Sydney, Australia.
Lines: 39

In article <633@philica.ica.philips.nl> adrie@beitel.ica.philips.nl (Adrie Koolen) writes:
>I agree with you in that the stated FS is more elegant than a threaded FS.
>But both solutions have to solve two main problems. The first is that many
>messages, sent from the FS to a task, are hidden in a deeply nested function.

I prefer threads. They neatly solve this first problem. The nested context
is automatically preserved with a separate stack for each thread, at least
after many global variables are made local or put in the fproc table. (The
defines in fs/param.h hide an alarming number of globals).

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.

>The second problem is that the FS also uses the tasks for its own purposes.
>When reading a file, the FS has to read an i-node and possibly some indirect
>blocks to access the data in the file. Each time the FS calls a task, you
>must decide where to continue after the reply is received. And believe me,

Deciding where to continue is automatic with the above approach. Note that the
restriction to at most one thread sending to a driver task simplifies many
things. It is necessary because the device tasks are now single-threaded like
FS. (This is not so harmful as for FS. It penalizes mainly devices with
independent minors, and makes it impractical to put anything but short-term
strategies in the drivers.) It probably makes competition for resources like
disk buffers less of a problem.