Making a queue of threads in C++

Question

I'm trying to run threads one after the other. I know I could do them serially but the whole point is so the commands don't block the UI.

However, in the implementation I came up with, I can't use std::thread because I can't pass threads as a parameter.

Is there another way I can do this?

This is my current implementation:

#include <mutex>
#include <thread>
#include <queue>

class ThreadQueue {
    std::queue <std::thread> threads;
    std::mutex mutex_add;
    std::mutex mutex_remove;

public:
   ThreadQueue() {}

    ~ThreadQueue() {}

    void add(std::thread thread) {
        mutex_add.lock();
        threads.push(thread);
        mutex_add.unlock();
    }

    std::thread remove() {
        mutex_remove.lock();
        std::thread thread = threads.front;
        threads.pop();
        thread.join();
        mutex_remove.unlock();
    }
};

You need to spend some time learning how Multithreading works, how c++11 threads work, and also some general information about c++; the code presented here suggests you don't currently have working knowledge sufficient to work with this kind of problem. — Xirema, Jun 15 '16 at 20:23
You should rather use a queue of functions and let one thread handle them all, one after the other. — tkausl, Jun 15 '16 at 20:23
@juanchopanza I think what he meant is that he could run some processing serially (as in in one thread) but doesn't want to block the UI. — freakish, Jun 15 '16 at 20:28
Also since you use separate mutexes for `add` and `remove` then your code is not thread safe (not to mention that without lock guards there's a deadlock possibility, at least in `remove` function). — freakish, Jun 15 '16 at 20:36
@Chad That solves the problem technically, but not from the root. — πάντα ῥεῖ, Jun 15 '16 at 20:45
@πάνταῥεῖ: I have not idea what you mean by `but not from the root` — Martin York, Jun 15 '16 at 20:52
@LokiAstari Obviously that design is flawed, at least quite odd. — πάντα ῥεῖ, Jun 15 '16 at 20:56
@πάνταῥεῖ There is not enough info in the question to support that conclusion. — Martin York, Jun 15 '16 at 20:59
@LokiAstari Well, even with `std::move()` that design would suffer from efficient use of the available cores in parallel. — πάντα ῥεῖ, Jun 15 '16 at 21:10
@πάνταῥεῖ That depends on how fast threads are added and the size of the job. There is not enough information to determine the merits of the design. — Martin York, Jun 15 '16 at 21:19
@LokiAstari I was extending my answer with some more aspects ... — πάντα ῥεῖ, Jun 15 '16 at 21:22

score 4 · Accepted Answer · edited May 23 '17 at 12:22

I know I could do them serially but the whole point is so the commands don't block the UI.

Is there another way I can do this?

As it was already mentioned std::thread is a movable class type and you could use std::move() to transfer them in the queue.

But I don't think it's a good design to use a queue of std::thread instances.

Let's suppose you're placing a thread instance to that queue that utilizes a thread function, it will be started immediately. So then, what's the role of the queue here?
Should the thread pop itself from the queue as soon it was started? Who's going to join() it then?

As @alexeibs suggests you should have one thread, that executes UI background tasks (e.g. std::function objects) that are read from the queue.

You could even have such task queue being shared by multiple threads (aka thread pool), and maximize your available CPU cores' utilization (ideally you shouldn't have more active threads than CPU cores available).

The synchronization (mutexes, condition variables for notifying etc.) should be applied to the queue itself then.

A possible implementation can use a boost::asio::io_service class: http://stackoverflow.com/a/37829164/3461423 — alexeibs, Jun 15 '16 at 20:52

Martin York · Answer 2 · 2016-06-15T21:01:32.960

2

You can move threads:

So you can simply fix your code like this.

void add(std::thread&& thread) {
          //        ^^   
        mutex_add.lock();
        threads.push(std::move(thread));
          //         ^^^^^^^^^
        mutex_add.unlock();
    }

But saying that there are other ways to solve this that may be better.

Rather than having a queue of threads that can be added and removed. Have an queue of jobs that are executed by a thread(s) owned by the object. Or you can simply use std::async() to start jobs in the background.

edited Jun 15 '16 at 21:01

answered Jun 15 '16 at 20:46

Martin York

257,169
86
333
562

Well, suppose the thread is running now after the `std::move()` applied. What's the role of the queue then? When should the thread instance be `pop()`ed from it? – πάντα ῥεῖ Jun 15 '16 at 21:39

Making a queue of threads in C++

2 Answers2