Calling a function with different number of threads passed to the application

Question

I have a function which needs to be invoked with a different number of threads each time (am doing some performance calculation, so need to know when the performance starts deteriorating). Example is given below:

getTime() {
    return 0;
}

int main() {
    boost::threadpool::thread_pool<> threads(nThreads);

    for(int j = 0; j <= nLines; j++){
        threads.schedule(boost::bind(&getTime, nThreads, 1));
    }

    threads.wait();
}

Where, nThreads: A value given at the command line

My question is, would this give me the desired result, as to would this call the 'getTime' function with 'nThreads' each time the for loop is accessed by the program? Or do I need some other method to find out the same?

what i really want to do is this:

boost::threadpool::thread_pool<> threads(nThreads); 
// start a new thread that calls the "getTime" function 
for(int j = 0; j <= nLines; j++){ 
    //threads.schedule(boost::bind(&getTime, nThreads, 1));
    threads.schedule(boost::bind(&getTime, 0, nLines, pc)); 
}

(not sure which of the above is correct.)

the getTime() function is to be run with a specified number of lines which i get from a text file and give each line to a api, whose performance i wish to calculate. but this is unrelated to the question i have.

i wish to call a function with different number of threads each time and calculate how much time it took each thread to finish. what was the total time taken with 1 thread, what was the total time taken by 2 threads to finish, etc.

Answer 1

If i understand correctly, what you really want to do is something like this :

int main() 
{
    int nbThreads = 20;
    boost::threadpool::thread_pool<> threads(nbThreads);

    for(int threadId = 0; threadId <= nbThreads ; ++threadId)
    {
        threads.schedule(getTime);
    }
    threads.wait();  
}

If i am right, you don't need to use boost::bind here.

Note that Boost.ThreadPool is not part of Boost (yet? it ). It will be reviewed, but no review date has been planned yet.

Answer 2

What about using something like OpenMP? If scalability is your goal, it's probably a better choice.