Echelon Neuron C - Manual (Page 147)

Neuron C Programmer’s Guide 135
{
// build a message
// send the message
}
when (msg_completes)
{
msg_out.tag = t;
// This sequence is not
// recommended.
msg_out.code = 1; // Causes a device reset
// if the system is
// already in preemption
// mode
}
Instead of using this sequence, build messages and call msg_send( ) in a task
with a when clause that does not use the msg_completes event. When you
update synchronous output network variables, preemption mode is entered at the
critical section boundary if there are insufficient application output buffers to
accommodate the updates. For example, if you update three synchronous output
network variables in a critical section and only two application output buffers are
available, preemption mode is entered upon leaving the critical section. The
application leaves preemption mode and returns to normal operation after all the
outstanding network variable updates are buffered.
When implicit buffer allocation is used (that is, building an explicit message
without calling msg_alloc( ) first), then preemption mode is entered upon the first
assignment to msg_out if no application output buffer is available. Preemption
mode ends as soon as a buffer becomes available (that is, when a completion
event is processed). While a device is in preemption mode, no outgoing network
variable updates occur, priority or otherwise. Thus, a program that expects
priority updates to occur within a bounded amount of time should
not use
nonpriority synchronous network variables or messages with implicit buffer
allocation.
To allocate and free buffers explicitly, use the functions described in Allocating
Application Buffers on page 143.
You can detect whether or not a program is already in preemption mode with use
of the following function:
boolean preemption_mode (void);
This function returns TRUE if the device is in preemption mode. The application
must include the <status.h> file to use this function.
Asynchronous and Direct Event Processing
You can check events using when clauses and events such as when
(msg_completes), when (msg_fails), and when (msg_succeeds). This type of event
processing is referred to as asynchronous processing , because the scheduler
handles the exact order of execution. An alternate technique is direct event
processing , in which you check completion events inside tasks, with if and while
statements.