[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Priority revisited: a new primitive
> > > 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
I feel we might loose the "composability" aspect:
the prioritisation scheme of one process might affect
some other... in a complex way...