Path: utzoo!dciem!nrcaer!sce!graham
From: graham@sce.carleton.ca (Doug Graham)
Newsgroups: comp.os.minix
Subject: Re: Assorted questions
Message-ID: <878@sce.carleton.ca>
Date: 17 Jul 90 04:25:43 GMT
References: <24719@nigel.udel.EDU>
Organization: Systems & Computer Eng. Dept.,Carleton University,Ottawa,Canada
Lines: 91

In article <24719@nigel.udel.EDU>, HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) writes:
> I think the aim of all this has nothing to do with parallel computing.
> It has to do with readability of code (note that I do not say it IS
> readable as it is, but it WAS the intetion).

My point is though, that splitting a program into tasks should not be
done for readability, because invariably, it has the opposite effect.
Tasking should only be used to deal with asynchronous events, although
even then, I'm not convinced they are the best approach because things
get complicated when abnormal conditions such as signals must be dealt with.
Aside from the readability aspect, splitting an inherently sequential
algorithm into tasks is just begging for deadlock as can be seen in
earlier versions of Minix, and as can be seen in the ugly hacks to avoid
it in the current version. For example, it used to be, that when FS
needed to generate a SIGPIPE, it would send a message to MM. The problem
was, that MM could have been simultaneously trying to send a message
to FS via. tell_fs. Deadlock! Actually it was even worse than that,
because in the course of handling the SIGPIPE, MM would send an UNPAUSE
message to FS. But FS was still waiting for a reply to the original
request. In the current Minix, FS sends the SIGPIPE message to to SYSTASK,
which passes it to MM after checking that MM is actually waiting for it,
and replies immediately to FS, so FS can get the UNPAUSE later.
This is all far too complicated, and it would all go away if MM and
FS were not separate tasks.

> On a PC, there is quite a trivial reason doing it so:
> The address space of the kernel is to small to make all these procedures
> fit in it.

Actually, except for the buffer cache, current Minix will fit quite nicely
into 64K split I&D. Note that when you get rid of all the extra tasks, you
can dump a fair chunk of duplicated code (e.g. printk only needs to be
loaded once, not thrice), and some code will go away because communication
is via procedure call, not message passing. There is other code than
could be tossed as well. The buffer cache need not reside in directly
addressable space; the buffer structures, instead of containing the data
itself, could contain a physical address pointer to the data.

> To speek for my own, I am VERY sure that all the MM stuff will go to the
> Kernel one day. On an ATARI, much of the real work MM does has been moved
> to the system task (look at the number of clock ticks each process consumes).
> The kernel-MM-interface is horrible regarding signals (with this point, you
> are right). It will even be much worse when MINIX is moved to a 386 etc
> platform with paging. It is nearly killing to send a message to MM on every
> page fault.

I wan't aware that there were any plans to implement virtual memory. I
thought Dr. T. has decided that VM is obsolete because RAM is so cheap
and plentiful. (I must be in the dark ages with my 640K XT). Is there
ongoing work in this area?

> The FS, on the other side, is nearly a self-contained entity that may remain
> a separate process. This has nothing to do with the fact it is realyy
> single-tasking - this will change in the future.

Yes, hopefully the single threaded FS will go away in the future, but,
although it would be possible implement a multithreaded FS in the same
manner as a read on a TTY is done now (with SUSPEND's and REVIVE's),
I think it would be madness to attempt this. Consider how many potential
places there are to block, when you do an open for example. You may
have to read many inodes, and many directories. At each blocking
point, you would have to save the state of the currently executing
system call, so that another could be started or resumed. In Unix,
this is easy, you just call wait, and the state is saved on the kernel
stack for the process. In Minix, you'd have to stash the state in
the "fproc" structure, and then return to the main processing loop.
Considering that the state would likely be spread over multiple
nested procedure calls, this could prove to be quite a feat.

There is also the problem of synchronizing access to global data
structures. Consider what happens when process P1 requests block B from
the disk, and blocks waiting for it. Now process P2 runs and requests
the same block. Presumably, the file system would notice that this
block was in transit, and block P2 somewhere. When the disk block
arrives, both processes should be awakened. In Unix, this is easy.
In Minix it's not. You'd probably wind up implementing something
like the Unix wakeup primitive.

The reason I bring all this up, is because somewhere in his book,
Dr. T. states that message passing is the more modern (and by implication
better) way of structuring an OS. As you can tell, I am far from
convinced of this. I don't necessarily think that Unix has all
the right answers either, but it seems that many of it's solutions
are more satisfactory than those of Minix, and perhaps Minix hackers
ought to be looking in that direction for ideas.

> C.v.W.

----

Doug.