[docs] State machine event handler semantics: atomic execution? about p

[ankushdesai]

Hi @oberstet, this is an excellent question.

A way to think about it is that each state machine is executing concurrently and the only shared state in the system (for which there can be race condition) is the inbox or message buffers. So, when any event handler in any state machine is executed, then yield or scheduling points are only inserted just before each send and receive operation so that the scheduler can interleave all sends and receives. Everything else thats executed between these sends is atomic as it only accesses local state.

Does this help?

[oberstet]

That way we can represent race conditions.

fwiw, the way that I look at this is: if I want to model realistically (eg a backend DB transaction is atomic, but not spanning a client message delivery) OR if I want to model an implementation in a "modern" programming language supporting asynchronous programming (eg. with futures/deferreds/promises or coroutines) then each "await/yield" point must be modeled as potentially branching into a new state sequence.

having a separate state machine for each asynchronous synchronization / branching point seems "wrong" .. that's my question - is it wrong? Do I fundamentally misunderstand P?

[oberstet]

then yield or scheduling points are only inserted just before each send and receive operation so that the scheduler can interleave all sends and receives

yes, that clarifies the semantics for me, thanks! I can see the systematic/symmetry in this design. unfortunately, that's what I did suspect:( as the consequence is:

in an asynchronous program, every yield/await is a scheduling point, an independently scheduled continuation. the entry point to such a task/coroutine is a scheduling point, as is the return point. and while the latter 2 map nicely to state machine message handler entry and send message calls, the former is more general:

asynchronous continuation context can be nested, and this must be mapped to 1 state machine per asynchronous continuation context and message passing for yield/await.

eg in the "1_ClientServer" tutorial example, one would need more state machines to separate out the DB transaction and the sending of the client reply. separate from consuming a request from the inbox of the main server FSM.

practically, with such an application, stuff like this can happen:

• the app backend sent the DB transaction, but the backend crashes before receiving a DB reply
• the DB at this point now might or might not have committed
• likewise, once a DB commit success was received in the app backend, the backend might send the client reply, and before the client receives the reply, the client crashes
• ...

anyways. it'll depend I guess. however, looking from this "async app programming" perspective, I am wondering:

what I really need to exhaustively explore all possible state sequences of an async single-threaded app implementation would be: automatically use every future/promise/deferred/coroutine as a scheduling point.

those are exactly the branching points in the state sequence of such a program. wrt to the event loop / reactor (the "green threads" scheduler), not the OS of course. OS scheduling adds more branch points.

[oberstet]

I should probably add: I am mostly socialized in the context of monolithic kernels with mostly blocking system calls, and then using a green threads user program scheduler with async/await or the like. and then create a distributed app using instances of such a program.

IOW: never used microkernels, and though I have used purely message passing systems such as Erlang/OTP and purely functional (monadic IO) languages in the past, I have mostly moved to async/await style which "seems more natural".

Yeah, I know, I am not believing hard enough;) If I try very very hard, I can think about programs as just sets of assertions. Well, it seems my patience for such brain puzzles is getting lesser the older I get;) Doesn't feel natural. For me. Anyways, just my 2cts being a regular programmer ..

[oberstet]

then yield or scheduling points are only inserted just before each send and receive operation so that the scheduler can interleave all sends and receives

just rethinking this: actually, one should be able to create a devnull process that throws away every message it receives, and then just use send(devnull) to effectively yield/await at any point within an event handler?

[ankushdesai]

You can yield/await within an event handler using the receive statement in P. Which is similar to await in C#.

https://p-org.github.io/P/manual/statements/#receive

Not sure if this is what you are hinting towards in your last message?