0

I'm in the design phase of development and am considering using multi-threading in C++ to implement some functionality. I'm familiar with the basics of multi-threading but wanted to get others take on my idea. I haven't chosen a multi-threading library yet (leaning towards Boost) but my question is probably independent of the library chosen.

Basically I would have a class (let's call it CommandGenerator) that executes in a while loop (until terminated) and checks a message queue of commands that is populated by another piece of software. Every time CommandGenerator gets a message off the queue, I'd like it to spawn a thread that executes in the background and works with the data just pulled off the queue. Meanwhile I want CommandGenerator to continue to run and come around the while loop again and pull any new messages and again spawn more threads. Is this conceptually possible? Can I keep spawning threads and just let them run in the background until they complete while the code continues to loop and check the queue? CommandGenerator will not need to have control over the threads. They would be able to execute independently once created and are guaranteed to terminate but may take up to a minute to finish executing (they wait a certain amount of time specified in the message pulled off the queue before executing).

Any input is appreciated.

Improve this question
4
  • 1
    I recommend you to use the built-in C++11's threading module. Commented Apr 25, 2013 at 12:53
  • 1
    C++ includes thread support in its standard library. See the <thread> header. Commented Apr 25, 2013 at 12:54
  • 2
    Are you familiar with multithreading concepts like Producer-Consumer or the Thread Pool pattern? Commented Apr 25, 2013 at 12:55
  • 1
    Look up @Coral Doe stuff - it will help you. Usually, threads do not poll queues, actively looking for work - they are signaled when work is available on the queue. Commented Apr 25, 2013 at 12:59

3 Answers 3

Reset to default
2

What you want to do is called a "producer-consumer" pattern.

I would strongly advise against creating a new thread for each message received: if you did that and you get too many messages at once you can clog up the machine.

Instead, have a fixed number of consumer threads that read the message queue, and let them handle one message at a time. If too many messages come at a single time they will be stored in the queue, waiting to be processed.

Since you have a delay between fetching the message and actually processing it, again the solution IMHO is not to spawn one thread per message but just to increase the number of your consumer threads. This way you can keep resource usage under control. How many threads exactly you will need is totally dependent on your application, you will have to find this out yourself.

As for the implementation, if you use C++11 you just need std::thread / std::mutex and std::condition_variable. If you use C++03 then boost has the equivalent classes.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

0

Yes, your concept is quite feasible. However, nominally you'd have an upper bound on how many threads that can be spawned. The bound can be large though.

Improve this answer

Comments

0

Your concept is feasible and quite close to some regular multi-threading patterns. One pattern is to use have a shared thread safe queue. You have a producer, in this case your CommandGenerator that pushes work onto the queue. You then have consumer threads that sit waiting for something to be put onto the queue. When an item is pushed onto the queue, one (and only one) of the threads is able to take the item off and process it.

One way to implement this is using std::thread and std::mutex.

Depending on the compiler you're using, you should seriously look at std::async. This can remove the burden of needing to know what threads will be created and when.

You will need to make sure you know what happens when you need to stop processing. For example, when your CommandGenerator is stopped, should it wait for processing threads to stop? How are command processing threads stopped? What happens to items still in the queue? These are design decisions that you will need to think about (if you haven't already).

Improve this answer

2 Comments

Thanks for the input, I appreciate it. Just to clarify, for this application I can assume that CommandGenerator will never be stopped. All it will do is start up and wait for messages on the queue and create 1 or more threads for each. Again, to clarify the logic behind thread creation, each message will have 1-5 wall clock times in it. A thread will be created for each time in the message and all the thread will do is wait until the time it was given is >= currentTime and then do something (for simplicity sake, say it just prints it's thread id to stdout). After that, the thread is done.
In the meantime, while each thread is waiting to execute (up to a minute later) I still want CommandGenerator to go and pull any new messages off the queue and spawn more threads.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.