AAStarted and AAEnded messages to become AAHappened

[AndreVanDelft]

In ACP atomic actions are really atomic. In SubScript these are much related to code fragments. However, some kinds of code fragments may take longer than just a conceptual moment:

• {threadedCodeFragment}
• @gui: {fragment for invokeLater}
• {fragmentWithADurationForDiscreteEventSimulation}
• {... loopingEventHandlingCodeFragment ...}

To handle such cases a distinction has been made between the start and the end of atomic actions, even though this is self-contradictory. As a result we have now AAEnded messages sent around in the call graph that immediately follow AAStarted messages, namely for the normal code fragments. As we are now in the process of defining the optional break behavior in the context of parallelism, it appears necessary to have a simple notion of an atomic action, and to stick close to ACP terminology. That is: an atomic action may happen, which means start and end at the same time. So we should replace the AAStarted and AAEnded messages by AAHappened messages. For first 3 kinds of long lasting code fragments listed above, two of such AAHappened messages should be sent: one the start of the code fragment (say the opening brace) and one for the end of the fragment (the closing brace). A loopingEventHandlingCodeFragment should issue an AAHappened message each time when such an event is handled.

[anatoliykmetyuk]

I agree on the point that we should replace AAStarted and AAEnded with AAHappened. Really, we should closely stick to the concept and don't sacrifice the idea for the sake of correct implementation.

I'm not sure, however, about the long-lasting code fragments that fire multiple AAHappened messages. In my opinion, we should better stick to the theory and don't sacrifice it for the sake of implementation. If we can't possibly treat an action as an atomic, then we'd better just break it into several really atomic actions rather then making it fire multiple AAHappened.

Here's what I guess we should do in order to make the VM closer to the theory: First of all, we should define what is atomic action - both in ACP theory and in the context of our environment. Should an action be considered atomic only if it's not interrupted by other actions within the VM thread, or should it be considered atomic only if it's not interrupted by any other action from any existing thread? Then we should determine the nature of all existing code fragments and classify them into atomic and non-atomic. For example, {threaded code} (write *something* in order to print '*' symbol) can hardly be treated as an atomic action, in my opinion, because it clearly involves at least two separate events (start and end of the thread) sequential execution of which can be interfered by some other atomic actions taking place under same parallel n-ary operator. Finally, we should make all the fragments to behave in an appropriate and natural way - if necessary, we should split some fragments into a sequence of multiple atomic actions.

[AndreVanDelft]

My intent was not to sacrifice theory; my experience so far is that the implementation must stick closely to the theory in order to be correct and simple.

Long ago, when I worked on Scriptic, an atomic action corresponded one-to-one with a code fragment. For most code fragments this works well. However some flavours emerged during the course of the years that are not atomic any more. For these code fragments the start and end of the execution should be regarded as atomic actions.

I just did a google search on acp "atomic action" start end duration -scala and I found this paper: http://alexandria.tue.nl/extra1/wskrap/publichtml/9811593.pdf by Baeten and Bergstra. On page 6 it introduces durational actions, which is characterized by an atomic start action and an atomic end action. So that is the same as I proposed here (as I remember, Jan Bergstra told me of this approach about 20 years ago).

Now these durational actions in general do not interrupt one another; they are assumed to happen concurrently. SubScript and the VM are more or less just interested in the start and end of these actions; whatever happens in between is a matter for an external system.

I think the move to AAHappened messages will be easy:

• 1 for each (vey) normal code fragment and for (single) event handling code fragments
• 2 for each threaded code fragment and for each codefragment executed using SwingUtilities.executeLater().
• a variable number for each looping event handling code fragment

[anatoliykmetyuk]

So the atomic actions are assumed to be actually atomic only for the VM, right? Roughly, VM executes one atomic actions at a time, it's not physically capable of executing 2 atoms at a time.

Also, we shouldn't make a special case of SwingUtilites.executeLater(). There are lots of other frameworks with alternative ways to launch threads, we can't consider all of them. We need a general solution for threading.

Also, in my opinion, we should use AAStarted and AAEnded messages in case of durational actions for clarity. After all, these durational actions' nature is not atomic.

In case of loops, I guess the variable number of AAHappened messages will naturally be the case, because every loop takes place on a set of entirely new atomic actions.

[anatoliykmetyuk]

And, by the way, this issue is not so critical for optional break implementation: if atoms usually just fire AAStarted-AAEnded in sequence, then if we change that to only one AAHappened, in almost all cases (except threaded code) this will be just the same thing as to rename AAStarted into AAHappened and remove AAEnded.