С++ ThreadPool не работает параллельно

Я использую boost::asio для реализации пула потоков. Надеюсь это поможет. Эта реализация была взята из пула потоков Asio. Для меня ключом к тому, чтобы пример работал, является область asio::io_service::work и наличие join_all за пределами этой области.

#include <boost/chrono.hpp>
#include <boost/thread.hpp>
#include <boost/asio.hpp>
#include <boost/scoped_ptr.hpp>
#include <iostream>


boost::mutex output_mutex;
void call(size_t job_number)
{
    {
       boost::mutex::scoped_lock print_lock(output_mutex);
       std::cout << "Hi i'm job << " << job_number <<" and thread: " << boost::this_thread::get_id() << std::endl;
    }

    boost::this_thread::sleep_for(boost::chrono::seconds(2));
    {
       boost::mutex::scoped_lock print_lock(output_mutex);
       std::cout << "job " << job_number << " finished. thread " << boost::this_thread::get_id() << " ready." << std::endl;
    }
};

int main(int argc, char **argv)
{
    size_t number_of_threads = boost::thread::hardware_concurrency();

    // the number of jobs does not have to equal the number of
    // threads.  they will be processed in turn.
    size_t number_of_jobs = 3 * number_of_threads;

    boost::asio::io_service io_service;
    boost::thread_group threads;
    {
        boost::scoped_ptr< boost::asio::io_service::work > work( new boost::asio::io_service::work(io_service) );
        for(size_t t = 0; t < number_of_threads; t++)
        {
            threads.create_thread(boost::bind(&boost::asio::io_service::run, &io_service));
        }

        // post the jobs for work
        // notice that the thread id is reused
        for( size_t t = 0; t < number_of_jobs; t++ )
        {
            io_service.post(boost::bind(call,t) );
        }
    }
    threads.join_all();

    return 0;
}

Проблема в функции run: g_lockqueue слишком долго заблокирована. Он заблокирован, пока locker находится в области действия, поэтому g_lockqueue блокируется при вызове pop.
Но, поскольку pop и empty не должны выполняться одновременно, вам нужно вернуть "Работу", пока она заблокирована, а затем снять блокировку. , и, наконец, выполнить работу.

run может выглядеть так:

void run()
{
    while (!bIsReady || !m_workQueue.empty())
    {
        Work work;
        {
            std::unique_lock<std::mutex> locker(g_lockqueue);
            if (m_workQueue.empty())
            {

                while (!g_notified) // used to avoid spurious wakeups 
                {
                    g_queuecheck.wait(locker);
                }
                if(!bIsReady)
                    g_notified.store(false);
            }
            work = m_workQueue.pop();  // get the work to be done while locked
        } // g_lockqueue released here
        work.do();  // do the work
    }
};

1. Как я могу это исправить?

Вы не показываете фактическую работу, только pop вызывается. Предполагая, что это действительно выполняет функцию, вы должны отметить, что ваш std::unique_lock все еще находится в области видимости, когда вы это делаете, поэтому он синхронизирован. Вам нужно освободить блокировку, чтобы вызовы были одновременными, что означает, что блокировщик должен быть вне области действия.

Например,

    { // begin locker scope
        std::unique_lock<std::mutex> locker(g_lockqueue);
        if (m_workQueue.empty())
        {

            while (!g_notified) // used to avoid spurious wakeups 
            {
                g_queuecheck.wait(locker);
            }
            if(!bIsReady)
                g_notified.store(false);
        }
    } // end locker scope
    m_workQueue.pop();

Обратите внимание, что теперь ваш метод pop будет запускать функции параллельно, но он также будет параллельно изменять очередь. Это проблема. Вам нужно будет сделать что-то вроде: переместить функцию в локальную переменную, а затем вытолкнуть, удерживая мьютекс; затем вызовите функцию вне области шкафчика.

2. Что-то еще не так с моим ThreadPool?

Вы используете глобальные переменные, что некрасиво, и ваши переменные плохо названы: совершенно не ясно, что означают g_notified и bIsReady.

3. Является ли ожидание лучшей практикой?

Нет. Даже если не считать самой ошибки, ее намерения неясны.