How should i map Windows thread priority macros to Linux?
 

HI *,
i am porting Windows based application to Linux and facing some difficulties while mapping some thread prority macroes(Windows) to respective Linux values.

As far as i know thread priorities in Windows vary from 1(Lowest) to 31(Highest) where in Linux it varies from 1(Lowest) to 99(Highest).Is this information correct?

Now following are the Macros i am using in Windows for which i want corrosponding values in Linux....

THREAD_PRIORITY_NORMAL 24
THREAD_PRIORITY_TIME_CRITICAL 31
THREAD_PRIORITY_HIGHEST 26
THREAD_PRIORITY_ABOVE_NORMAL 25
THREAD_PRIORITY_BELOW_NORMAL 23
THREAD_PRIORITY_LOWEST 22


Please help ):

That is incorrect; from the 'nice' manual pages:

And from the setpriority() man pages:

[edit] Just to complicate things a bit more, users may be limited in the range of schedule priorities they can request. You need to use sched_get_priority_{min,max}() to get the range you're allowed. Also, I can't remember if different pthreads may have different priorities or if priorities can only be assigned per process (in which case fork() processes can have different priorities but not pthread() processes).

" nice values are actually represented using the corresponding range 40..1 (since negative numbers are error codes) and these are the values employed by the setpriority() and getpriority() system calls."

so which values should i use corrosponding to following priorities?

THREAD_PRIORITY_NORMAL 24
THREAD_PRIORITY_TIME_CRITICAL 31
THREAD_PRIORITY_HIGHEST 26
THREAD_PRIORITY_ABOVE_NORMAL 25
THREAD_PRIORITY_BELOW_NORMAL 23
THREAD_PRIORITY_LOWEST 22


and if windows have these Predefien Macros corrosponding to thread priority values, doesn't Linux have the same kind of Macros?

1. It is absolutely ridiculous to think that a priority value in one system would map to a priority value in another system with the same effect; one (of numerous) contributing factor is the mechanics of the system's scheduler. On top of that, priority values must be set according to individual situations in order to achieve the desired performance. In applications where the priority does in fact matter, you cannot simply set a value and presume that is the correct value for different situations.

2. I can only guess that MS has defined those macros as some sort of guide to programmers; the names themselves have no special meaning whatsoever. As I have already mentioned, priorities need to be set on a case-by-case basis and the behavior depends on the implementation of the scheduler. In reality there is no guarantee that your software will meet requirements on a particular system even if you always requested the highest priority, so setting fixed priorities does not make sense. What would make sense is to test at runtime if requirements are being met and to escalate priority as required; keep in mind that it is possible that requirements cannot be met due to other circumstances such as high load.