How to setup and manage persistent multiple threads?

I have POSIX in mind for implementation, though this question is more about architecture.

I am starting from an update loop that has several main jobs to do. I can group those jobs into four or five main tasks that have common memory access requirements. It's my idea to break off those jobs into their own threads and have them complete one cycle of "update" and sleep until the next frame.

But how to synchronize? If I detach four or five threads at the sta开发者_如何学编程rt of each cycle, have them run once, die, and then detach another 4-5 threads on each pass? That sounds expensive.

It sounds more reasonable to create these threads once, and have them go to sleep until a synchronized call wakes it up.

Is this a wise approach? I'm open to accepting responses from just ideas to implementations of any kind.

EDIT: based on the answers so far, I'd like to add:

• concurrency is desired
• these worker threads are intended to run at very short durations <250ms
• the work done by each thread will always be the same
• i'm considering 4-5 threads, 20 being a hard limit.

That depends on the granularity of the tasks that the threads are performing. If they're doing long tasks (e.g. a second or longer), then the cost of creating and destroying threads is negligible compared to the work the threads are doing, so I'd recommend keeping things simple and creating the threads on demand.

Conversely, if you have very short tasks (e.g. less than 10-100 ms or so), you will definitely start to notice the cost of creating and destroying lots of threads. In that case, yes, you should create the threads only once and have them sleep until work arrives for them. You'll want to use some sort of condition variable (e.g. pthread_cond_t) for this: the thread waits on the condition variable, and when work arrives, you signal the condition variable.

If you always have the same work to do every cycle, and you need to wait for all the work to finish before the next cycle starts, then you're thinking about the right solution.

You'll need some synchronization objects: a "start of frame semaphore", an "end of frame semaphore", and an "end of frame event". If you have n independent tasks each frame, start n threads, with loops that look like this (pseudocode):

while true:
  wait on "start of frame semaphore"
  <do work>
  enter lock
  decrement "worker count"
  if "worker count" = 0 then set "end of frame event"
  release lock
  wait on "end of frame semaphore"

You can then have a controller thread run:

while true:
  set "worker count" to n
  increment "start of frame semaphore" by n
  wait on "end of frame event"   
  increment "end of frame semaphore" by n

This will work well for small n. If the number of tasks you need to complete each cycle becomes large, then you will probably want to use a thread pool coupled with a task queue, so that you don't overwhelm the system with threads. But there's more complexity with that solution, and with threading complexity is the enemy.

The best is probably to use a task queue.

Task queues can be seen as threads waiting for a job to be submitted to them. If there are many sent at once, they are executed in FIFO order.

That way, you maintain 4-5 threads, and each of them executes the job you feed them, without needing to detach a new thread for each job.

The only problem is that I don't know many implementations of task queues in C. Apple has Grand Central Dispatch that does just that; FreeBSD has an implementation of it too. Except those, I don't know any other. (I didn't look very hard, though.)

Your idea is known as a thread pool. They are found in WinAPI, Intel TBB and the Visual Studio ConcRT, I don't know much about POSIX and therefore cannot help you, but they are an excellent structure with many desirable properties, such as excellent scaling, if the work being posted can be split up.

However, I wouldn't trivialize the time the work takes. If you have five tasks, and you have a performance issue so desperate that multiple threads are the key, then creating the threads is almost certainly a negligible problem.