RE: Priority revisited: a new primitive

[M_Boosten <mboosten@xxxxxxxxxxxxxxxxxxx>]

> > > The fact that one talks about (1) PRI PAR, (2) PAR, (3) PRI
> > ALT, (4) ALT,
> > > and (5) PAR PRI tells me: all this is TOO COMPLEX!  Something is
> > > FUNDAMENTALLY WRONG!
> >
> 
> I also think that the learning cycle is not too complex. Students pick it up
> easily because this concept is relatively simple and clean. For some is
> understanding and learning the look-and-feel of the PAR, ALT, PRI PAR, PRI
> ALT, SEQ, and PAR PRI all together confusing and therefore complex . perhaps
> unnecessarily complex. On one hand, these keywords capture most fundamental
> artefacts of the real-time and concurrent world . nevertheless; this is a
> confusing world. On the other hand, we need to leave out what we don't need.

You can build complex CSP processes, that depend on the
_priorities_ for correctness.  I (feel) that this should
not be encouraged.

I think programs should be correct, independent of the
priorities.  Priorities should only affect the
performance, the order, but not the correctness of the
order.

I feel we might loose the "composability" aspect:
the prioritisation scheme of one process might affect
some other... in a complex way...

Cheers,
	Marcel