I’ve a core 2 duo processor.
I want to create and run eight threads(that have no shared data in between them) such that in any given time all eight will run once where thread 1 and thread 2 will run at the same time and if thread 1 and thread 2 can’t run simultaneously by the processor I want priority be given to thread 1 so that thread 1 will run before thread 2.
Similarly thread 3 and 4 can run concurrently but if thread 3 and thread 4 can’t run at the same time I want thread 3 to execute before thread 4 and not before thread 1 and 2 and not after thread 5 and 6 and thread 7 and thread 8.
Same for thread 5 and thread 6, thread 7 and thread 8.
After all 8 threads have finish their tasks the 8 threads will run again and again in the above given order until termination.
How can achieve this using c++ and visual studio 2008 on Windows 7?
Is it possible to implement this with c++?
Ok, after a lot of wrangling to actually get the question out of you, here’s the version I’m going to try to answer:
And luckily, the answer to that is fairly simple. Your program doesn’t know which threads are run when. The OS doesn’t tell you when it starts and stops a thread, so you can’t code any kind of “is thread 1 running? If not, I’ll pause and let that run” check.
But you can set the threads to have different priorities. That indicates to the OS which ones it should schedule for execution. Give your threads a gradually decreasing priority (so thread 1 has a high priority, thread 2 one step lower and so on), and you’ll have made something that kind of approximates what you want. On Windows, this might actually work out fairly well, since Windows always tries to pick the highest prioritized threads/processes available. Linux will try to ensure that all threads get some execution time, but will simply give more to higher prioritized ones.
And of course, messing with priorities like this also affects how your program is scheduled in relation to everything else running on the PC. You’re really trying to go about this the wrong way, and the saner solution would be to simply find another scheme for parallelizing this.