Re: proposed new definition of preemption

Le 26 feb 2013 à 14:39, Jim Barnett a écrit :

> On your third point, I think that you are right that targeted transitions will conflict if one’s source state is a descendent of the other’s, but that is not the only condition under which they conflict.  Consider a parallel element P with children S1, S2, and put transitions in S1, S2 that both exit P and go to different remote states (i.e., ones that cannot be simultaneously active).  The transitions in S1, S2 conflict, but neither’s source state is a descendent of the other’s.

Indeed, but in that case S2's source state will have been exited by S1's exit step, and I meant that the preemption based on source states' hierarchical relation would fix the method relying on source states being exited (you pointed out yourself that it didn't work all the time) rather than replace it. Since computing the hierarchy between tree nodes is very fast, and then testing whether a state is still active is just one operation, the result is a simple, basically linear algorithm that doesn't need compilation to quickly determine which transitions to take.

I think the exit set definition is "simpler" (not to implement, but to read) so I don't mind if it goes in the spec. The problem with the approach described above is that it effectively does what we define as "preemption" in two separate parts of the code (first remove hierarchical conflicts, then remove other conflicts during the exit step).

		David