|
channel message has incompatible lengths
|
When you are sending a message through a channel, whether or not this is routed through a link to another processor, the sending and receiving sides must agree on the length of the message.
|
|
channel transfer on badly bound port
|
It is possible to pass a parameter to a task by binding one of its ports to an integer value, using the configuration language BIND statement. The task should not then try to do a channel transfer through this port.
|
|
ill-advised alterations to CPU registers
|
You should change CPU registers only if you are certain about what you are doing. It is easily possible to disrupt the microkernel in this way.
|
|
multiple use of run-time library
|
Many parts of the run-time library cannot be used by more than one thread at a time. In a multi-threaded task, you should wait for the semaphore par_sema before using run-time library functions marked as server, or use the special protected versions of certain functions which are defined in par.h.
|
|
multiple use of shared object
|
If two or more threads are using the same data area, link, etc, it should be protected by a semaphore or by some other technique, to ensure that conflicting accesses do not occur.
|
|
no memory assigned to STACK or HEAP
|
If you assign a size to either the HEAP or STACK logical area in a TASK statement in your configuration, but do not assign a size to the other, the other will be given no memory. Nearly all tasks fail under these conditions.
Either assign values to both or use the DATA logical area, which is shared by the two of them. One task on each processor may have no data assignments; this task is given all the available remaining memory for its DATA logical area.
|
|
not enough memory assigned to logical area
|
If the stack or heap overflows the assigned memory area, the application will usually fail.
|
|
two threads waiting on one channel
|
If a thread tries to do a read on a channel, the thread waits until another thread does a write on it; at that moment, the transfer happens. If, during the time the thread is waiting for the transfer to take place, a third thread tries to do a read on the same channel, the effects are unpredictable.
The same applies if a thread tries to do a write on a channel, and has to wait for another thread to read the data; if a third thread tries to write to the channel, the effects are unpredictable.
|
|
|