Я пишу потоковое приложение на C ++. Ниже приведен пример кода, показывающий, как я проверяю количество потоков. Мне нужно убедиться, что в любое время из моего приложения появилось только 20 рабочих потоков:
#include<stdio.h>
using namespace std;
class ThreadWorkerClass
{
private:
static int threadCount;
public:
void ThreadWorkerClass()
{
threadCount ++;
}
static int getThreadCount()
{
return threadCount;
}
void run()
{
/* The worker thread execution
* logic is to be written here */
//Reduce count by 1 as worker thread would finish here
threadCount --;
}
}
int main()
{
while(1)
{
ThreadWorkerClass twObj;
//Use Boost to start Worker Thread
//Assume max 20 worker threads need to be spawned
if(ThreadWorkerClass::getThreadCount() <= 20)
boost::thread *wrkrThread = new boost::thread(
&ThreadWorkerClass::run,&twObj);
else
break;
}
//Wait for the threads to join
//Something like (*wrkrThread).join();
return 0;
}
Будет ли этот дизайн требовать от меня блокировки threadCount
? Предположим, что я буду выполнять этот код в многопроцессорной среде.
Дизайн не достаточно хорош. Проблема в том, что вы раскрыли конструктор, так что, нравится вам это или нет, люди смогут создавать столько экземпляров вашего объекта, сколько захотят. Вы должны сделать что-то вроде пула потоков. у вас есть класс, поддерживающий набор пулов, и он выдает потоки, если они доступны. что-то вроде
class MyThreadClass {
public:
release(){
//the method obtaining that thread is reponsible for returning it
}
};
class ThreadPool {
//create 20 instances of your Threadclass
public:
//This is a blocking function
MyThreadClass getInstance() {
//if a thread from the pool is free give it, else wait
}
};
Таким образом, все обеспечивается внутренним классом объединения. Никогда не передавайте контроль над этим классом другим. Вы также можете добавить функции запросов в класс пула, такие как hasFreeThreads (), numFreeThreads () и т. д.
Вы также можете усовершенствовать этот дизайн с помощью интеллектуального указателя, чтобы вы могли следить за тем, сколько людей все еще владеет потоком.
Возложение ответственности за освобождение потока от людей иногда опасно, поскольку процессы завершаются сбоем и они никогда не возвращают протектора, есть много решений, самое простое — поддерживать часы в каждом потоке, когда время истекает. забирается силой.
Других решений пока нет …