Path: utzoo!attcan!uunet!mcsun!tuvie!inst182
From: inst182@tuvie (Inst.f.Techn.Informatik)
Newsgroups: comp.os.minix
Subject: FS (was: Re: Assorted questions)
Message-ID: <1685@tuvie>
Date: 17 Jul 90 16:00:29 GMT
References: <877@sce.carleton.ca> <628@philica.ica.philips.nl>
Reply-To: inst182@tuvie.UUCP (Inst.f.Techn.Informatik)
Organization: Technical University of Vienna, EDP-Center
Lines: 68

In article <628@philica.ica.philips.nl> adrie@beitel.ica.philips.nl (Adrie Koolen) writes:
>                The best solution to this problem would be to re-implement
>the FS as a 'stated' FS which returns to the main FS loop to send or
>receive messages. This approach requires quite complicated changes in the
>FS.

It would change the FS a lot, but I don't think it would be very complicated.
FS would look like this:

message_list	waiting_requests, requests_being_serviced;
message		messagein, messageout, messageaux;

for (;;) {
        receive (ANY, messagein)
        if (from_hardware (messagein)) {

                /* must be answer to previous request */
		messageaux = find_by_device (requests_being_serviced,
					     messagein.from);
		messageout = hardware2userprocess (messagein);
		send (messageaux.from, messageout);
		dequeue (requests_being_serviced, messageaux);

		/* device is free now, so send next request */
                if ((messageaux = find_by_device (
					waiting_requests,
					messagein.from)) != NOTFOUND) {
			messageout = userprocess2hardware (messageaux);
			send (messagein.from, messageout);
			dequeue (waiting_requests, messageaux);
			queue (requests_being_serviced, messageaux);
		}

	} else {
                if ((messageaux = find_by_device (
					requests_being_serviced,
					messagein.to)) != NOTFOUND) {
			/* device busy */
			queue (waiting_requests, messagein);
		} else {
			messageout = userprocess2hardware (messagein);
			send (messageout.to, messageout);
			queue (requests_being_serviced, messagein);
		}
	}
}

>FS. An easier method would be to create e.g. 3 FS threads. A FS, which
>waits in the main loop for a message is said to be free. User processes
>send messages to the FS, not knowing that there are 3 instances of the FS.
>A free FS is selected, which handles the request. When it sends a message
>to a task, the task replies to EXACTLY that FS thread. A FS thread cannot
>be interrupted by another FS thread, only by tasks. This feature can be
>used to garantee the consistency of the FS tables. This way, several
>processes can use the FS to access different tasks concurrently.

Yes that's possible, but I think one stated FS with queues is more elegant
than a fixed number of FS threads. And you could schedule the requests to the
same device (via elevator-algorithm, or something similar) more easily.
>
>Adrie Koolen (adrie@ica.philips.nl),
>Philips Innovation Centre Aachen

Peter J. Holzer (hp@vmars.tuwien.ac.at)

DISCLAIMER: It has been a while since I looked at the Minix sources, so
the above code segment is only a rough sketch, not something you could use.
But when I manage to get 1.5 I will look at the problem more closely.