revisiting preemption

There seems to be agreement that the existing definition of preemption is vague and confusing.   It can be made precise, but that still may leave it confusing.  This leaves us with three questions:


1.       Do we want another definition of preemption?  The obvious candidate is UML's definition:  two transitions conflict if their exit sets have a non-null intersection. We can tweak the definition based on transition classes/types to have the same semantics, so the real question is:  which definition is easier to understand?

2.       What do we want to do about targetless transitions?  They have an empty exit set, so on the UML definition they don't preempt any transitions and don't preempt any other transitions.  The existing definition (based on transition types/classes) says (in effect) that a targetless transition is preempted by any preceding transition that exits its source state.  This may seem intuitively clear, but it isn't necessary by any means.  The whole point of preemption is to block transition sets that could produce an illegal configuration, and targetless transitions will never do that.   By not preempting targetless transitions, we end up with the largest set of transitions that can be guaranteed not to cause problems.

3.       When we discussed this issue in the past, we decided that preemption is so complicated that it should be defined in a separate place, hence we have 'filterPreempted' as a separate function.  On the other hand, the filtering could be folded  back into the selectTransitions functions, particularly if it is based on the intersection of exitSets.   So we could consider getting rid of filterPreempted as a separate function.  However, if we do this, we have to insert the same conflict/preemption-detecting logic in both selectEventlessTransitions and selectTransitions, so it may be better to keep it factored out into a  separate function.


-          Jim