Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!ames!uhccux!virtue!comp.vuw.ac.nz!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: <2082@runxtsa.runx.oz.au>
Date: 31 Jul 90 11:07:54 GMT
References: <633@philica.ica.philips.nl> <2013@runxtsa.runx.oz.au> <883@sce.carleton.ca>
Organization: RUNX Unix Timeshare.  Sydney, Australia.
Lines: 26

In article <883@sce.carleton.ca> graham@sce.carleton.ca (Doug Graham) writes:
>"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 was hoping to use a minor variant of a method I use in some real-time code.
The only primitive is suspend(). That wakes up the next active thread on a
circular queue. The thread either does some real work or tests a flag to
see if it can proceed.

>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

You are right, there would have to be synchronization loops in a lot of
places. They might as well be made into library routines with names like
sleep() or wait() :-). The cache routines might end up looking like the
ones described in Bach's book instead of the current simple ones :-(.

What is there to worry about besides blocks and inodes? Probably everything
that eventually calls rw_dev, i.e. everything.
-- 
Bruce Evans
Internet: brucee@runxtsa.runx.oz.au    UUCP: uunet!runxtsa.runx.oz.au!brucee
(My other address (evans@ditsyda.oz.au) no longer works)