Threads FAQ entry incomplete (was: Alan Cox quote?)

[Stephen Satchell]

At 03:12 PM 6/19/01 -0600, Richard Gooch wrote:
>New FAQ entry: http://www.tux.org/lkml/#s7-21
>
>Yeah, it's probably a bit harsh :-)

It's also incomplete, in my view, to the point of being misleading.

Part of the reason I'm reacting so harshly to this FAQ entry is that it 
flies in the face of my own experience.  I do a lot of real-time and 
near-real-time programming, and find that the process and thread models are 
essential to the proper and expected operation of my code.  The FAQ answer 
neglects this entire area of applications.

For details:  I run a process (not threads as yet, but it will happen) for 
each event I need to react to in near real time.  The running priority of 
these processes are set as high as possible so that when the event occurs 
the newly-unblocked process is guaranteed to run almost immediately.  These 
processes, when unblocked, do the absolute minimum amount of work to meet 
the real-time requirements and then block again.  If an event requires 
extended processing to begin but not to complete in real time, the event 
process sends an appropriate signal to the main process to perform that 
extended processing.

The main problem with the comment in the FAQ entry that "it's easy to write 
an event callback system" is that the response time may not meet the needs 
of the application, particularly in computer systems that have multiple 
near-real-time applications running at the same time.

The key design point in this near-real-time model I have described is that 
it does not violate the rule of thumb described in the FAQ answer, that the 
Linux kernel is designed to work well with a small number of RUNNING 
processes/threads.  Ideally, a high-priority process should run for much, 
much less time than the standard time-slice so as to minimize the number of 
scheduler elements marked as "ready to run."  My standard is for a 
high-priority process driven by an event to run for no more than a 
millisecond or so, and leave any heavy lifting to the main process to take 
care of when the main process gets around to it.

For true real-time processing, you have to write device drivers to react to 
external events directly, a programming task that is more burdensome and 
error-prone.  Or, better, use a real RTOS instead of Linux.  When the 
real-time requirement isn't so critical, though, the method I have 
described allows the whole thing to be done in userland, where it can be 
debugged far more easily.

In summary, writing code to use many processes or threads is NOT lazy 
programming in all instances, as the FAQ answer implies.

Stephen Satchell
writing time-critical programs for only a short time -- 30 years.