Process objects

This is a note about processes-as-objects. It is my 14^th note, and my favourite theme so far has only briefly been touched. So, it is long overdue. Actually, the note is about process-oriented programming. I have worked with this type of programming of embedded systems most of my 30+? professional years. I seem to have gone through a darwinian evolution with my understanding of this programming paradigm. And in the future I probably will have to unlearn some, continue momentum, and perhaps even learn more. 

The simplest embedded program is one which runs in a "big loop", executing a set of small to very large state machines. It handles inputs and does its best to deliver expected outputs, in or on time.

Beneath any embedded program, interrupt functions handle things like communication, data conversion, timers, internal and external hw etc.

All access of common variables with the interrupt (often just called "asynchronous I/O") always must be protected. The simplest solution is for the big loop to disable the interrupt in mind, every place where data written by at least one of the parties.We allow Concurrent Read only by both parties, but require Exclusive Write, or CREW. The code block which ensures the exclusiveness protects the "critical region".

Big loop programming soon gets more complicated than necessary. When you discover that you are implementing something that smells scheduling, beware! Somebody has done this before. At this stage you should buy (or ask the guy next door) a small operating system. They are also called real time executive or kernel (rtx, rtk), task scheduler or run time system. Chanches are you'll never regret.

Processes keep their variables in a local storage, unique to each instance of a process. This store is often allocated from the system heap. The local data is often called its context. 

Processes are there for the programmer to be able to mentally grasp what's going on, and to encapsulate internal state. This makes it easier with processes than without.

Processes may communicate with messages. The transfer mechanism may be asynchronous or synchronous. The latter may be simpler to implement, provided some safe pattern to avoid deadlock is used. The two communicating processes would passively wait (block/descheduled) until the second contender is ready. Then the memcpy will occur, during the rendezvous. It follows from this that a potentially receiving process may passively hold a sender by not listening. Observe that this in no way implies busy polling, neither by the process nor the run-time system.

See [15] for a short example and additional description.

Such a process does not need to know the semantics (behaviour) of other processes, and need only relate to the message sequence diagram (protocol) used between the participants. This is often called WYSIWYG semantics. Asynchronous messaging lacks this feature. It may cause buffer overflow, so producer - consumer traffic must be balanced. With synchronous systems, any necessary asynchronousity is programmed with, or inside processes. 

With both these schemes, semaphores to protect common data are not needed.

Communication by passing pointers around with explicit ownership, by some mechansim, is also viable (also called zero copying). Otherwise, sending pointers in the two message passing systems mentioned, should absolutely be avoided. 

A process may deschedule itself (and rescheduled when some condition has been met: finished communication or timeout, or just to yield for others). This is called non-preemptive or cooperative scheduling. It's preemptive if an interrupt may call the scheduler, which may preemptively deschedule any process with a certain priority. Using many priorities should be avoided.