RE: [Boost-Users] set thread priority
I'd think you could get away with something like a set range, like 0 to 1000, and then map those values into whatever system is present. You could even use floating point values, 0.0 to 1.0, though people might look at you cross-eyed, at least until they got used to the idea. Then it's just a matter of mapping those ranges to whatever OS settings are present. You just state up front a couple caveats: Given two threads, A (higher priority) and B (lower priority), you only guarentee that A won't be given a lower underlying system priority than B. This would save you quite a bit of grief... particularly when someone wants threads with priority 1.0, 0.99 and 0.98. The thread with 0.98 might not run slower than the one with a 1.0 priority, but it certainly won't be faster. SOUNDS simple enough. At least to someone whose sum total multi-threading experience is a toy java applet and a dozen lines of boost::thread code. ;) --Mark Storer Software Engineer Cardiff Software #include <disclaimer> typedef std::disclaimer<Cardiff> Discard;
Mark Storer said:
I'd think you could get away with something like a set range, like 0 to 1000, and then map those values into whatever system is present. You could even use floating point values, 0.0 to 1.0, though people might look at you cross-eyed, at least until they got used to the idea. Then it's just a matter of mapping those ranges to whatever OS settings are present.
You just state up front a couple caveats: Given two threads, A (higher priority) and B (lower priority), you only guarentee that A won't be given a lower underlying system priority than B. This would save you quite a bit of grief... particularly when someone wants threads with priority 1.0, 0.99 and 0.98. The thread with 0.98 might not run slower than the one with a 1.0 priority, but it certainly won't be faster.
SOUNDS simple enough. At least to someone whose sum total multi-threading experience is a toy java applet and a dozen lines of boost::thread code. ;)
Some of the issues: * Min and Max values for priorities are platform specific. Not all platforms provide a means to determine these values. * Priorities are directly related to policies. You can't implement priorities with out addressing policies. * The Min and Max values on a single platform can vary by policy. * Some policies require other configurable settings. You get the idea. It's all very doable, but as usual it's more difficult than it at first appears. I've got a general design written up and just have to tackle implementing it. -- William E. Kempf
Take a look at ACE's ACE_Sched_Params class¹, used in conjunction with ACE_OS::thr_create()² or other thread-related facilities accepting a priority specification. Footnotes: ¹ http://doc.ece.uci.edu/Doxygen/Current/html/ace/classACE__Sched__Params.html ² http://doc.ece.uci.edu/Doxygen/Current/html/ace/classACE__OS.html#z108_1 -- Steven E. Harris :: seharris@raytheon.com Raytheon :: http://www.raytheon.com
Steven E. Harris said:
Take a look at ACE's ACE_Sched_Params class¹, used in conjunction with ACE_OS::thr_create()² or other thread-related facilities accepting a priority specification.
Thanks, I'm aware of ACE. As well as several other libraries that have done this as well. Only helps so much, however, and a lot is left to be done. -- William E. Kempf
participants (3)
-
Mark Storer
-
Steven E. Harris
-
William E. Kempf