archer%segin4.segin.fr@prime.com (Vincent Archer) (03/22/90)
In a message of 21 Mar 90 18:06, Jason Coughlin <jk0@sun.soe.clarkson.edu> says JC> I've seen quite a few messages go by of the form: JC> JC> "I hate the single-threadness of the filesystem because I throw JC> disk I/O jobs in the background..." JC> JC> People then say, "Well it's due to the fact that Minix has 1 message JC> mailboxes." JC> JC> People THEN say, "Well, I'm going to implement buffered mailboxes for JC> Minix." JC> JC> And then you don't hear anything else :-).... JC> JC> Could someone just explain the data-structures, etc. you use to JC> implement these buffered mailboxes in the kernel? You don't hear anything else from them because it's not the correct answer to the problem, I think :-)... The single-threadness of the File System does not come from the kernel being able to accept only one message at a time, it comes from FS working out only one message at a time... If you put a larger mailbox at the entrance to the filesystem, you will have processes posting faster messages, but waiting the same amount of time until FS replies! Currently, the FS behaves like this: +-> Get message ------some work-------> request from task | +--more work<----- reply from task | +----------------> request(2) from task | +------------- reply from task | many times this... +-- Reply to process <---+ (IO complete) A true multitask FS would be written as a state-driven program: +-> Get any message ----> find process context | | | V | change context | | | V +----------------- send a message to somebody The big difference between this behaviour and the previous one is that FS does not wait for the kernel tasks to reply, he just get any message from any process. If it's the reply, no problem, just continue until the next message (or final reply) need to be sent. If it's somebody else request, then you just pick the context needed, and work out the message in the same fashion. Now, why FS is not this way? Because state-driven programs are more complex, more intricate, and less readable than "plain" programs. Minix was intended as an educational tool, not something to baffle OS students! Vincent Archer Email to: archer%segin4.segin.fr@prime.com ---------
overby@plains.UUCP (Glen Overby) (03/24/90)
In article <14645@nigel.udel.EDU> archer%segin4.segin.fr@prime.com (Vincent Archer) writes: >In a message of 21 Mar 90 18:06, Jason Coughlin <jk0@sun.soe.clarkson.edu> says [Continuing the discussion about the bottleneack in FS Approach 1: Kernel buffers that won't help Approach 2: Making FS handle multiple requests itself ] The "sexy new operating systems all seem to have process threads (by whatever other name you want to call it) where several "threads of execution" share the same code and DATA spaces. I would like to offer Approach 3: Approach 3: RE-Implimenting FS under a threaded system Yes, this will require kernel support. The resulting FS will be more complex since locking on all global data structures will be a necessity. -- Glen Overby <overby@plains.nodak.edu> uunet!plains!overby (UUCP) overby@plains (Bitnet)
jk0@image.soe.clarkson.edu (Jason Coughlin) (03/25/90)
From article <3868@plains.UUCP>, by overby@plains.UUCP (Glen Overby):
> I would like to offer Approach 3:
WAIT!! I haven't seen the 1st response go by yet! Could someone pls
send me the articles on this subject? Since I started it, I would
like to read them. Bizarre...
--
Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx )
"Every jumbled pile of person has a thinking part that wonders what the
part that isn't thinking isn't thinking of." - They Might Be Giants