Date: Sat, 25 Mar 2006 18:43:02 -0600 (CST)
Subject: char device write causes pthread context switch
X-UID: 155

The multithreaded robot code will have to be broken out into multiple 
processes. That means another rewrite. As there is not too much code, it's 
not such a chore. The next iteration will make the third version. I want 
to test drive tomorrow so I should get busy.

Bit banged serial I/O with software delay loops works for receive but not 
transmit. The reason is that write() on the GPIO char device causes a 
pthread context switch. This messes up the delicate delay loop timing for 
the TTL serial pulses. What is surprising is that read() does not have 
this effect. This means the multithreaded robot code can receive from the 
microcontroller on the motor control board but not send to it.

It took a few hours of experimentation to figure this out.

I've found that separate processes can read() and write() on GPIO char 
devices without any bad effects. This is good. It means that what were 
multiple threads will have to be multiple processes.

Threads and processes are different. Traditionally, processes are heavy 
with course scheduling granularity performed by the kernel. Threads are 
lightweight with context switching done in the C library. This description 
blurs for modern implementations. Threads may be both in the kernel and in 
the C library.

I've tried to come up with a good theory for the behavior I'm seeing. But 
really, it's just the way it is. With an upgrade to the kernel, C library, 
or GPIO device driver, behavior could change. The multiple process 
solution just happens to work on the robot. It also happens to be a very 
traditional old school way of implementing a system on UNIX when you don't 
have threads available.

A RTOS (real time operating system) has timing and scheduling primitives 
explicitly addressing this. What I'm doing is writing the software around 
the undocumented (or poorly documented) idiosyncracies of Linux, which is 
not a real time OS. I think that there could be value in a deep 
understanding of how to do this. The reason is that while it is 
technically correct to use a proper RTOS, many still do the wrong thing 
and use non-RT Linux because it is cheap, easy, and convenient. Low cost 
and good enough usually wins out in the end.