Multithreaded C application framework or pattern

Question

I have been working on a multithreaded C (Linux) app for a while - a video recorder which has threads for audio and video capture, encoding, multiplexing and writing.

I started off throwing it together ad-hoc using pthread operations, but now I'm trying to expand it to support more states and refactor chunks of code that are popping up as duplicates to do with locking, setting flags and signalling a condition, and so on.

So far what I've come up with is something like this:

• Each thread should have a mutex lock and two conditions - one to wake the thread and the other to signal the thread has finished doing some work that another thread may be waiting for.
• Data queues are "owned" by a certain thread and protected using that thread's lock.
• Each thread needs the concept of "active" and "inactive" states and the ability to move between those and signal when done.

I'm planning to store the common elements in a struct and have an array of those structs that I can loop over to start, check and stop all threads.

As this turns into a more generic thread support model I thought I'm problably reinventing the wheel, so I'll ask here if there are some good known patterns I should be applying.

Answer 1

Your ideas remind me a lot of the active object computing model implemented in the QP state machine frameworks. Specifically, the QP/C and QP/C++ frameworks have been ported to POSIX (which includes Linux, BSD, etc.). The port has been described in detail in the Application Note "QP and Linux" available at: http://www.state-machine.com/linux/AN_QP_and_Linux.pdf.

Here are the highlights of the QP port to Linux:

• Each state machine executes in its own p-thread. The p-thread blocks on an event-queue implemented with a mutex and a condition variable. When the event queue receives an event, the thread unblocks and the event is processed by the state machine associated with this thread. (This is well known active object computing model.)

• Event queues are owned by the active object threads.

• Each thread has the whole hierarchical state machine, so it can have states "active" or "inactive'. Hierarchical state machines (UML statecharts) allow you to specify actions and transitions at higher level state and reusing this behavior in the nested states. This counteracts the state-transitions "explosion" that you have with traditional FSMs.