Re: pthreads and poll

[Kaz Kylheku <kaz at ashi dot footprints dot net>]

On Fri, 21 Jan 2000 kd@flaga.is wrote:

> So my problem is basically, I can be sleeping in the wrong call (poll() or
> pthread_cond_wait()) when the "other" event happens.
> 
> Am I thinking about this completely in the wrong way?

Sort of. Because a thread can't sleep in these two places at once, 
the best thing to do is to introduce another thread which is dedicated to
calling poll() and doing the related processing.

It's a fairly straightforward strategy: identify the blocking inputs or outputs
in your system and dedicate a thread to each one.

A lot of multithreaded software can be written without any condition variable
waits at all.  That is to say, condition variable delays are often removable by
having the signalling thread actually do whatever work it wants the signalled
thread(s) to do.

Of course, that is not always the best strategy, because you want the
architecture to be balanced; and particularly to have a predictable response
latency from threads that respond to internal events.

For example, in a communication protocol stack that I maintain, the low level
drivers have receiver threads that listen for input, dequeue it and form it
into the proper packet buffer representation. Then they call upward to a
central module where packets are deposited into a global queue, and a condition
variable is signalled. This variable wakes up a receive processing thread which
removes the packets from the queue and drives the input functions of the higher
layer protocols.

The condition variable wait could be removed by having each receive thread
drive the protocols directly, but that would introduce a big random delay into
their execution path, possibly causing them to miss input packets, or
lowering throughput.

This is analogous to not doing a lot of work in interrupt service routines of
an OS, but rather delegating compute intensive work to some deferred task
processing.