ZT0009%DMSWWU1C.BITNET@cunyvm.cuny.edu (Kai Henningsen) (07/24/90)
I personally think that lightweight threads (coroutines) are the way to go - at least for a part of the solution. Some of the primary benefits would be: * No need to change most of the code - we have a very simple way to save all context that is in auto variables (switch to another coroutine). * Very simple management of critical sections - switches between coroutines occur only where explicitly programmed. * A single adress space in FS, so we can share global data without problems. I have an implementation of coroutines that uses only setjmp/longjmp plus the possibility to change the stack pointer (+ frame pointer) saved in the jmp_buf; about one screenful of C-Code. It would get better if a special (assembler) library routine for creating a new coroutine were used, something like Modula-2 SYSTEM.NEWPROCESS; currently, this needs a bunch of longjmp()s just to set up an initial stack. The point is that this does not need *any* kernel support (except to tolerate when the stack pointer goes below the brk value). The number of coroutines could even be made dynamic! Now, as I said above, that would only be part of a solution. Also needed would be the famous queuing messages (to prevent FS blocking because the disk driver is busy). Also, the disk driver would have to use coroutines as well - probably two: One to do actual I/O, the other to wait for messages and build sorted lists of requests. Maybe every task could benefit from this model? A central coroutine that does central management, one or more "slave" ones to do the dirty work that could be suspended whenever they have to wait. Of course, as I said above, the kernel messaging scheme would need a major overhaul. We might as well split it from user-to-kernel-messaging completely. (As someone suggested, it's not for user libraries to know that there are FS and MM (and no others), and which does what.) I think the main benefit of this idea would be that it does not do too much damage to existing code. By the way, someone said MM would have to go kernel because of virtual memory. Not quite. Virtual memory consists of low level as well as high level problems. I'd prefer a low level "paging device driver" (maybe SYSTASK could foot the bill) and a high-level MM. For example, as long as a process needed only pages already granted by MM, the driver could do it all; when a reference outside is made, or all free pages are used up, the process could be blocked and a message sent to MM, which would have to decide what to do (for example, which pages to dump to a swap area). This, by the way, will invariably introduce recursion in the kernel. Assume two processes sharing mmap()ed memory (it's in POSIX, isn't it? So we would want to have it). Or even only one process. A write() inside this space comes to FS. FS calls the kernel to assure the relevant pages are present (or maybe a driver does? or calls MM?) This one, in response, decides to page them in from the real file on disk. Who knows where this file is? Yes - FS! So, a message gets sent back to FS. At this point, FS MUST be able to interrupt the previous write to do the new read. Current FS cannot do that. Kai
brucee@runxtsa.runx.oz.au (Bruce Evans) (07/29/90)
In article <25468@nigel.udel.EDU> ZT0009%DMSWWU1C.BITNET@cunyvm.cuny.edu (Kai Henningsen) writes: >Also, the disk driver would have to use coroutines as well - probably two: >One to do actual I/O, the other to wait for messages and build sorted >lists of requests. This is not essential. Better make FS multitasking first. The sorting now done done by FS works fairly well, and sending i/o vectors is more efficient than a lot of little messages. >Of course, as I said above, the kernel messaging scheme would need a major >overhaul. We might as well split it from user-to-kernel-messaging completely. If you change almost everything to use threads, it would hardly be worth keeping the current task structure, and the system would no longer be Minix. -- 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)