Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucsd!usc!elroy.jpl.nasa.gov!ames!uhccux!virtue!comp.vuw.ac.nz!munnari.oz.au!csc!csc3.anu.oz!ccadfa!rodos2!wkt
From: wkt@rodos2.cs.adfa.oz.au (Warren Toomey)
Newsgroups: comp.os.minix
Subject: An FS idea - good or bad?
Message-ID: <1766@ccadfa.adfa.oz.au>
Date: 24 Jul 90 05:48:24 GMT
Sender: news@ccadfa.adfa.oz.au
Lines: 32

I have had some ideas about alleviating the FS's single-threadedness, so
could someone please explain where I've gone wrong.

Assume the FS doesn't block on a read/write to a device task, but just
sends the request to the task, marks the block in the cache as `in transit',
saves the user's request info somewhere [as extra fields in the cache?],
and goes back to the main loop.

Eventually, the FS will receive a reply from a device task, and then it
can reply to the requesting process that has been blocked all the time.
At this point, it can note that the device task is now `waiting for a
request'.

The problem is of course, what should the FS do if it needs to send a request
to a device task that _isn't_ `waiting for a request'? If it does so, it will
block.

One alternative is to store a queue of outgoing read/write requests, and
this queue can even be reordered to improve efficiency at the device level.
However, this queue is probably static. What should be done if the queue
of device requests fills up, and no device tasks have replied yet?
Throwing away user requests is not a good idea.

Can anybody suggest ways around this problem? Or is it just a bad idea?!


Cheers,


    Warren Toomey VK2XWT, chocolated.
 Deep in the bowels of ADFA Comp Science.
        `Shut up Nick - jem'