abbott@VUSE.VANDERBILT.EDU (Ben Abbott) (08/21/88)
The following questions were posed: > Problems using the Event in 3L Parallel C: > We are using a Transputernetwork for some Realtime-Signal-Processing. > To synchronize our software-processes with the surrounding hardware we intend > to use the Event-Request. The transputer-pin Event is connected with a > periodic timersignal (period = 5..800 ms). > 1. Question: > ----------- > Is the following function correct? > #include <chan.h> > void synchronize() > { > char ch; > > chan_in_byte(&ch, EventReq); > chan_in_byte(&ch, EventReq); > } > 2. Question: > ----------- > Has anybody experience using Event in Multithreaded tasks. > We are synchronizing the different threads using the semaphore functions of > Parallel C. > As long as we do not synchronize the hole task with the hardware using event, > all threads proceed. Otherwise several threads do not get their start > semaphores, allthough the sema_signal() function has been called in the > main thread with the right arguments. > The system behaves like some semaphores would get corrupted by the > synchronize() function. ---------------------------------------- Question 1 looks ok to me. However, you might want to use chan_in_byte_t for error handling. Actually, I have not used the event pin to trigger a thread but caution you against mixing Urgent (like those associated with an event) and Non-urgent threads with the same semaphore. 3L implementation (as with most) requires the SIGNAL and WAIT routines to not be interrupted or sliced. For Urgent threads this is obviously the case even when an event occurs since it will not be recognized until the current thread releases control (chan_in, chan_out, timer_delay,...). For non-urgent threads they ensure those machine instructions which allow time slicing to occur arwwwwe not in the SIGNAL and WAIT routines. The Event would restart an Urgent thread even in the middle of a non-urgent semaphore operation. For this reason 3L states not to mix Urgent with non-urgent across the same semaphore. Instead, they suggest the use of channels for synchronization between these two. The above discussion as well as the use of a stack rather than a queue for threads waiting on a semaphore has caused me to write my own version for my application (I wish it could be given away but the G-men won it). ---------- One further thought... We have been doing some real (that is real signals and A/D's) real-time work as well. A problem arose that required chan_in_..._t to be written on our own. It did something strange was happening like always waiting for the timeout period to pass even if input was received before the timeout. In any case the code would work when no timeout were used on I/O operations. Then simply adding these in all sorts of bad things happend. After I wrote my own, everything was fine. Hope this was a help TTFN, Ben Abbott