Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!osu-cis!att-cb!cbosgd!wright!dhemm From: dhemm@wright.EDU (David Hemmendinger) Newsgroups: comp.lang.misc Subject: Re: Modula-2 Process Scheduling Design Error Message-ID: <369@wright.EDU> Date: 4 Apr 88 19:01:40 GMT References: <4538@xanth.cs.odu.edu> <130@oresoft.UUCP> Organization: Wright State University, Dayton OH, 45435 Lines: 56 Keywords: reference SIGPLAN notices Summary: Modula-2 process-scheduling design error In article <130@oresoft.UUCP>, randy@oresoft.UUCP (Randy Bush) writes: > In article <4538@xanth.cs.odu.edu> kent@xanth.UUCP (Kent Paul Dolan) writes: > >SIGPLAN Notices . . . has two useful Modula-2 articles. > >The first is "Unfair Process Scheduling in Modula-2", and points out a > >flaw in the semantics of the "send" command as it interacts with the > >usual (recommended by Wirth) single ready-run process scheduling ring > >of most (all?) Modula-2 implementations. I missed Dolan's posting that remarked on my SIGPLAN note. The flaw I point out there is not in the "send" routine, but solely in the scheduler outlined in Wirth's book. > > This article points out one of the well-known flaws in a trivial > scheduler library module which was put in the book for tutorial purposes > only, not a flaw in the coroutine mechanism of the language. I am glad to hear that the flaw is well-known; I had not seen any discussion of it. Though part of a "trivial" library module, this is the scheduler provided as a module in all the compilers I've seen that provide a scheduler at all. None of these includes any suggestion that the scheduler is of limited utility. > I am not aware of anyone ever trying to use that module for anything > serious. If you hear of such, tell them not to. Authors of the Modula Research Institute's RT-11 compiler, of the Volitions Systems compiler, and of the Logitech compiler (1985 version, at least): take note. > Take a look at Jirka Hoppe's Nucleus instead. If this refers to Hoppe's "A Simple Nucleus Written in Modula-2" paper in Software-Practice and Experience, v. 10, I am puzzled. As I noted in my paper, Hoppe's scheduler, which uses message-passing for synchronization, uses a queue of ready processes. However, since a process that sends a message puts itself at the _front_ of the ready queue, _precisely_ the same unfairness results: a single producer-consumer pair will starve other processes, except that now the unfairness is quite independent of the order of starting the processes. > Actually, everyone I have met who is doing > 'real' process models is rolling their own from NEWPROCESS, TRANSFER, > and some interrupt mechanism such as IOTRANSFER. That's what's nice > about a language where one is given the primitives, not someone else's > preconceptions of what's right for you. As my paper remarks, this is indeed the virtue of Modula-2, and experienced programmers will take advantage of it. I suspect, however, that most uses of Modula-2 do not involve its coroutine or process features. I was conjecturing that one reason may be that this intrinsically difficult subject is made more difficult for beginners by such problems as unfair scheduling (as well as by other defects in the compilers or scheduler modules they provide). -- David Hemmendinger CSNET: dhemm@CS.wright.EDU UUCP: ...!cbosgd!wright!dhemm Computer Science Dept., Wright State University, Dayton, Ohio 45435 +1-513-259-1345