An OO consumer/producer design?

[Mookie]

All the Example code in the Threading section are coded in the older style of subclassing QThread. One of the problems I see with this is that every consumer then spawns its own thread.

I have a slow system and have a need for a "best effort" object on a thread. i.e. A consumer that keeps up as best it can with small inputs that come in too fast. If it's busy and 2+ more inputs come in it only processes the latest one on the next iteration. My previous implementation was a loop in the QThread::run() function with a mutex protected input block and a binary semaphore to control the loop. When not in use, the thread merely locks the loop and waits.

As stated above, this has the limitation that every consumer must spawn its own thread. I was hoping to modify this into multiple producers connected to multiple consumers, which could be moved to a generic thread context using moveToThread().

The problem: This architecture provides no concept of "skipping" inputs that are coming too fast. The consumers residing on their own, shared thread rely on the thread's event loop. There's no look-ahead capability to see if a newer signal of that type is waiting in the queue. Has anyone tackled this issue? Ideas?

[wysota]

What you have is not a classic producer-consumer situation. Have a mutex (and possibly a wait condition) protected variable where you assign the latest input. If the consumer doesn't manage to process it before the producer kicks in, the producer will overwrite content of the variable with new input and signal the consumer, there is work available. There is no benefit of having an event loop here so subclassing QThread and reimplementing run() is the proper way to go.