13

If you write software where the customer pays for the number of CPU cores the software uses, then what would be the best way of achiving this in your C++ code? My research so far has led me to use SetProcessAffinityMask on Windows and sched_setaffinity on POSIX systems.

  • True and detailed answer for your question : [1]: http://stackoverflow.com/a/3082553/1848929 – hakki Feb 26 '13 at 00:50
  • @hakiko That question is about finding out how many cores there are... – us2012 Feb 26 '13 at 00:51
  • 2
    On Windows, you should have a look at job objects: http://msdn.microsoft.com/en-us/library/windows/desktop/ms684161(v=vs.85).aspx they can do a lot more for limiting processes than affinity. But they also can limit affinity: http://msdn.microsoft.com/en-us/library/windows/desktop/ms686216(v=vs.85).aspx – Simon Mourier Mar 08 '13 at 10:53
  • Is this your software or their software? How much control do you have over the machines? How exactly did you want to model your measurement metrics: If the software uses one core for most of the time but touches another core for 10 cycles are you going to count that as using two cores? – Roasted Yam Mar 10 '13 at 14:33
  • 1
    "he customer pays for the number of CPU cores the software uses" - it's important how those cores are counted - if you don't run more thread than cores allowed, no more cores will be used any given time. Some OS-es will schedule those threads to all available cores from time to time, so it's up to computer owner how to count it. Mentioned functions should keep system from freely moving threads around, so that makes your question answered already. – j_kubik Mar 11 '13 at 06:44

2 Answers2

2

That's an interesting question. I don't think I have the perfect solution, but since there has been no response so far, let me suggest the following:

If the main chunk of work in your program is done by one type of thread, just don't spawn more worker threads than the customer's license allows. As a single thread can't be divided to run on multiple cores, this imposes a hard limit.

(I don't think setting process CPU affinity is the way to go as it can be easily changed at runtime. Since it doesn't require any reverse engineering or permanent modifications to the system, I would be worried that circumventing this doesn't feel "bad" enough to prevent even the honest customers from trying it.)

us2012
  • 16,083
  • 3
  • 46
  • 62
  • Setting thread quotas may also be a way of doing this. When it comes to people changing the process affinity at runtime I thought that I would occasionally check the affinity with `GetProcessAffinityMask` and throw a licensing exception(exit) if it has changed since I first set it in `main`. –  Feb 26 '13 at 09:32
0

I think you found the best option. Limiting the number of threads is not a good idea if you want to take advantage of the capabilities of multithreaded processors.

Sputnik
  • 168
  • 2
  • 7
  • 1
    "where the customer pays for the number of CPU cores" already implies that you do NOT want to take advantage of those capabilities, UNLESS the customer pays. – MSalters Mar 15 '13 at 11:08