kent@xanth.cs.odu.edu (Kent Paul Dolan) (03/23/88)
I'd just like to direct the readership's attention to the March 1988 SIGPLAN Notices, which 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. This looks a lot like a "gotcha!" if you are really using M2 for a multiple process tasking system. The second is "What does Modula-2 need to Fully Support Object Oriented Programming". It is a nice (brief) tutorial on OOP, as well as a careful analysis of the strengths and weaknesses of M2 with respect to OOP use. There are _lots_ of code examples showing how to make OOP work, and showing what clumsy artifices are required where the M2 OOP support is weak due to a mismatch between the language and the programming paradigm. Can anyone comment on Oberon with regard to features supporting OOP? Did Wirth consider OOP in the design of Oberon? I've directed followups (about Oberon) to comp.lang.misc. Kent, the man from xanth.
randy@oresoft.UUCP (Randy Bush) (03/30/88)
In article <4538@xanth.cs.odu.edu> kent@xanth.UUCP (Kent Paul Dolan) writes: >I'd just like to direct the readership's attention to the March 1988 >SIGPLAN Notices, which 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. This looks a lot like a >"gotcha!" if you are really using M2 for a multiple process tasking >system. 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 not aware of anyone ever trying to use that module for anything serious. If you hear of such, tell them not to. Take a look at Jirka Hoppe's Nucleus instead. 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. So, in summary, It does not seem to look like a gotcha for those of us who are using M2 for a multiple process tasking system. -- randy@oresoft.uu.net FidoNet:1:105/6.6 randy%oresoft.uu.net@relay.cs.net +1 (503) 245-2202 { ..!mcvax!uunet, ..!textronix, ..!sun!nosun } !oresoft!randy
dhemm@wright.EDU (David Hemmendinger) (04/05/88)
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