🚀 go-pugleaf

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