1

Initially, I'm getting the number of cores in a system.

int num_cpus = (int)std::thread::hardware_concurrency();

After that i created lambda function for thread compution function

auto properties = [&](int _startIndex)
    {
      for (int layer = _startIndex; layer < inputcount; layer += num_cpus)
        {
           ..........//body
        }
    };

calling thread function and joining the thread

std::vector<std::thread> orientation_threads;
    for (int i = 0; i < num_cpus; i++)
    {
        orientation_threads.push_back(std::thread(properties, i));
    }
    for (std::thread& trd : orientation_threads)
    {
        if (trd.joinable())
            trd.join();
    }

I'm getting the result correct but I want to change the thread allocation method. means, Initially, 8 thread is executing in 8 core 1st thread->1st core like this all 8 thread is allocated. 5th thread is executed first remaining 7thread is still executing. now the 5th core is free I want to allocate 9th thread to 5th core. like all thread should allocate based on which core is free

AravindK
  • 151
  • 8
  • 2
    In general, you typically don't worry about trying to schedule a thread on a particular core unless you are doing something very advanced. The operating system does this for you automatically. I don't believe there's any guarantee that each thread runs on the same core when it resumes from preemption anyway. There are however, OS APIs that will control thread affinity with respect to number of processors/cores. – selbie Jan 24 '20 at 04:37
  • Links for thread affinity apis on both [Win32](https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-setthreadaffinitymask) and [pthreads](http://man7.org/linux/man-pages/man3/pthread_setaffinity_np.3.html) – selbie Jan 24 '20 at 04:40
  • You probably want to use a concurrent / thread-safe queue. For some examples, see https://stackoverflow.com/questions/7817364/are-there-any-concurrent-containers-in-c11 – jtbandes Jan 24 '20 at 04:43
  • 1
    The OS's default thread-to-core scheduling algorithm has likely been very finely calibrated to match the hardware it is running on; I wouldn't try to second-guess it too much. (in particular, always trying to spread the threads evenly across cores is *not* necessarily the optimal strategy, since things like cross-core communications overhead and power-usage minimization can make it better/faster to leave some cores idle in some circumstances, on some hardware). If you do end up pinning threads to cores, be sure to measure to see if it actually improved your program's performance or not. – Jeremy Friesner Jan 24 '20 at 06:06

0 Answers0