This paper builds on an earlier paper

"From message queue to ready queue" (also by this author)

• "Case study of a small, dependable synchronous blocking channels API". [See there]
  
• "Ship & forget rather than send & forget"
• In ERCIM Workshop on Dependable Software Intensive Embedded Systems, Porto, 2005
• Both papers are "industrial" (A term not existing (yet?) in WoTUG)
• What has happened "after Porto" is described in the present paper. [See here]

Program and architecture wear

After Porto: Errors and Modifications

• Errors: Run-time System Malignant Schedulings Removed

1.1 - Problems with timeouts

1.2 - Problems with not clearing "first" on all channels

• Modifications: Architectural Patterns Extended

2.1 - Two asynchronous channels

2.2 - Overflow buffer and no asynchronous channel

SDL and this "CHAN_CSP" layer

• Both: Non-preemptive. Run to completion. One message queue. No priority
  
• Both: "Process" scheduled by msg queue. "Driver" when queue is empty (cannot receive msg)
• CSP layer: channel OUT, IN, ALT, with timeouts on the two latter
• CSP: Asynch channel is data-less; input side equal to any other channel. One only per "round" for no overflow

API and ALT

API functions are all wrapped in macros:

#define CHAN_INIT_F                (CHAN,SENDER,RECEIVER,ALTTAKEN)
#define CHAN_IN_F                  (CHAN,DATA,EVENT)
#define CHAN_IN_VARLEN_F           (CHAN,LEN,DATA,EVENT)
#define ALT_CHAN_IN_F              (GUARD,CHAN,DATA,EVENT,ALTTAKEN)
#define ALT_CHAN_IN_VARLEN_F       (GUARD,CHAN,LEN,DATA,EVENT,ALTTAKEN)
#define ALT_CHAN_IN_ASYNC_SIGNAL_F (GUARD,CHAN,EVENT,ALTTAKEN) 
#define CHAN_OUT_F                 (CHAN,DATA,EVENT)
#define CHAN_OUT_VARLEN_F          (CHAN,LEN,DATA,EVENT)
#define CHAN_OUT_ASYNC_SIGNAL_F    (CHAN,RESCHEDULEME) 
#define CHAN_IN_ASYNC_SIGNAL_F     (CHAN,EVENT)|
#define ALT_TIMER_IN_F             (GUARD,TIME,UNIT,EVENT,ALTSTATE,ALTTAKEN)
#define FSM_RESCHEDULE_F           (EVENT)

Example of an ALT:

case ST_STATE_IN_ALT_200_202_204_301_A:
{
    bool_a alt_taken = FALSE;
    g_ALT_LH         = CHAN_ALT_ENABLED_ON_A;
    CP->Timer_xxx    = CHAN_TIMEOUT_MS;
    Guard_ModifyAny(CP);
    //
    ALT_CHAN_IN_ASYNC_SIGNAL_F (CP->Guard_202i, g_chan_202, S_EVENT_ALT_202_A, &alt_taken);
    ALT_CHAN_IN_ASYNC_SIGNAL_F (CP->Guard_204i, g_chan_204, S_EVENT_ALT_204_A, &alt_taken);
    ALT_CHAN_IN_F              (CP->Guard_200i, g_chan_200, CP->Chan_200i, S_200_A, &alt_taken);
    ALT_CHAN_IN_F              (CP->Guard_301i, g_chan_301, CP->Chan_301i, S_301__A, &alt_taken);
    ALT_TIMER_IN_F             (CP->Guard_Tim, CP->Tim, TU_MS_A, S_TIME_A, &g_ALT_LH &alt_taken);
    //
    CP->State = ST_STATE_IN_ALT_200_202_204_301_END_A;
}
break;

"From message queue to Ready Queue"

• "Ready queue" == "Scheduling queue" here
• SDL bottom: two N constant sized memcpy per transfer
• CSP layer: one memcpy in rendezvous, data-less in queue

Implementing CHAN_CSP in an existing tradition

• The author "sold to" do it in 2-3 weeks (because we had "SPoC to look at")
• The tradition in 2002 in the company was
• C and asynchronous SDL type messaging (mature in-house run time system present)
• OO/UML was approaching for embedded applications
• Channels or/and SDL or/and OO/UML (uncertainty: menu or decree?)
• The author made one API header file, and we had to modify in the SDL runtime system with some #ifdef's
• It was up and running surprisingly fast, and used in a product, but (after Porto)
• with new users, and usage, we had to admit Trojan reschedulings
• we needed more software process data-flow patterns
• There was an increasing unease with
• asynchronous buffer overflows
• missing client process protection against unwanted messages

1.1- Problems with timeouts

• Two time constructs: 1.) Time outs on channels and delays with no timers involved, 2.) higher level application level timeouts. Problems with 1.)
• The underlying problem: the SDL layer had no way to remove unwanted timeouts, even if cancelled
• A timer event might be from an older timer, since long forgotten
• The SDL solution, was to "colour" a timer event, and flush it once it arrived in the process
• However, a CSP process is not allowed to be shaken by unanticipated scheduling
• Alas, we had filtered as a function of the ALT state only
• This worked fine until a new user began using a channel and timeout as not part of an ALT
• Almost 100% safe is to colour a timer with present process scheduling count and have the run time system throw away a timer if present scheduling count is not unchanged
• 100% safe only if we know that the normal number of reschedulings do not wrap around and up to same value
• We use a 16 bit counter, and we assume-that-we-know it will not overflow
  

1.2 -  Problem with not clearing "first" on all channels

• A channel is not symmetric
• Being first on the sender side sticks forever (no timeout on output)
• Being "first" on the input side (if part of an ALT) may be cancelled..
• ..worse: it may reappear again in a completely different "ALT" setting
• If "channel first" is not cleared properly, the next real "first" causes a scheduling!
• No user code to "set up" and "tear down" an ALT (punished with this error)
• Worked fine with ALT after ALT, but not with IN after ALT
• Our new solution is to "Null" a set of channels when an ALT is taken
• those ever to participate in that ALT - that have this receiver side as "first"
• Cost: some run-time overhead. But still we managed without user application code
• "The Rubber Band of Getting it Right and Simple" (???)

2.1 - Two asynchronous channels

• Dotted lines are asynchronous data-free channels (before Porto we had only Chan_202)
• The pattern (above) handles deadlock free spontaneous sends "up" and "down". P_AutroBank is slave and P_Looper_Handler is master
• After Porto we added Chan_204 for high priority "escape-type" message handling
• Because a reply from Chan_202 could be 1) ok, come on 2) retry fast 3) retry slow
• In the retry phases no priority handling is present
• Could have been solved with extra sequences and the one asynch channel
• Building with channels is what occam programmers have done all the time - to solve application level semantics

2.2 - Overflow buffer and no asynchronous channel

• More simplification in protocol and internal state by allowing n(=one) packet down to be stored "in the channel"
• Up-going alarms or other (in sequence, actively pulled up) may cross a down-going spontaneous message (intertwined with "give me more" messages going down)
• Complex application level semantics (high pri alarms up vs. messages down)
• Still deadlock free as long as contract is respected

Conclusions

• C + functions/macro calls == process/data-flow also for embedded systems
• Once the channel functionality is in place, it always works
• Trying to explain why cannot be done too often:
• No interprocess malignant buffer overflows (even when no flow control beneath)
• Task "self protection" (even when one single queue beneath)
  
• Effect: each process becomes simpler, and the system sooner becomes right (provided..)
• A team member burst out with: “this is tenfold simpler than what I used to work with”
• Provision: correctly implemented run-time level!
• C (OK). Understanding channel runtime system (if needed, is worse)
• A good channel interface makes process/data-flow patterns easier modifiable

Links and contact info

• CPA-2006 home page: http://www.wotug.org/cpa2006/
• This lecture's corresponding paper: home.no.net/oyvteig/pub/CPA2006/paper.pdf
• The "Porto" paper: http://home.no.net/oyvteig/pub/ercim05_at_euromicro-2005/paper.pdf and http://home.no.net/oyvteig/pub/ercim05_at_euromicro-2005/workshop.pdf
• Feel free to contact the author at:

http://home.no.net/oyvteig/	http://www.autronicafire.com