FIFO semaphore quickie

James Buckle coyoteboyuk at
Fri Jun 10 17:54:41 CEST 2005

I'm trying to use a pair of  rtai FIFOs, created in a kernel module, with a 
second interface application. Kind of like an incoming and outgoing buffer 
of new data. The kernel module has absolute priority over the system and 
every time a packet arrives on a seperate serial link it checks to see if 
there is any new data to go in either direction. The kernel module basically 
keeps sending data as required by the hardware, even if its the same data as 
last cycle, or sends the next data from the FIFO queue if there is any 
there. At the end of every packet recieved it also transmits the latest data 
from the hardware back to the UI through the second FIFO.

I implemented this without semaphores and got a rather 'jerky and random' 
response from the hardware - telling a joint angle to go from A to G through 
B C D E and F often went A -> E -> G despite the UI having supposedly 
written all intermediate steps to the FIFO. I assumed this is due to lack of 
control over who has access to the FIFO at what time.

So i created FIFO semaphores, as described in the documentation, in the 
module, testing to see if its free or not before attempting to access it 16 
bytes at a time.

My question is now - when i run the UI side it locks the PC completely, i 
assume because im not checking the semaphore from in the UI and re-posting 
it when finished with it. Do i just use the FIFO name as in the module for 

Can you think of a better way of implementing a queueing system that might 
avoid any issues like this? The kernel module must always have priority or 
the serial comms will timeout on the hardware, but the UI needs to have 
sufficient calculation time to work on a few complex calculations.


More information about the Rtai mailing list