Question:
So if I have code like:
Runnable r = ...;
Thread thread = new Thread(r);
thread.setPriority((Thread.MAX_PRIORITY + Thread.NORM_PRIORITY) / 2);
or ...
Runnable r = ...
Thread thread = new Thread( new Runnable() {
public void run() {
android.os.Process.setThreadPriority(android.os.Process.THREAD_PRIORITY_MORE_FAVORABLE);
r.run();
}
});
IS the android.os.Process way required/preferred?
WHY is the android.os.Process way preferred/required if it is?
This is not clearly documented as far as I can tell.
Answer:
A: The current Dalvik implementation seems to map Java Threads ony by one to the underlying linux system PTHREADs like you say. All Threads of all apps belong on the same thread group on the system, so every Thread competes with all Threads of all apps.
So currently Thread.setPriority should actually do the same as
Process.setThreadPritority, using the smaller Java priority scale, the mapping of prioritys is defined in
kNiceValues at
vm/Thread.c
B: So it seems that process.setthreadpriority is preferred as there is a public defined group of priorities that dalvik uses whereas with thread.priority its a mapping that isn't public. Cool.
A: I just thought they both end up to the same OS api calls, so the only difference is the scale of the priority value. That means that even
Thread.setPriority sets a value competing with all app's Threads. So the decision for either method is merely a question of future safety, maybe if apps threads get grouped one time...
B: Hey Dronus, Yeah they do both call the correct pthread call. However, using Thread.setPriority() you are using a scale of 0-10 and on Process.setThreadPriority() you are using the nice scale (+/- 20). So Yes, nice is more granular but Thread.MIN_PRIORITY, NORMAL and MAX PRIORITY are not as informative and are somewhat arbitrary when the OS lib provided declares sets of priorities deemed expected and sane. Who knows what the mapping between the 10 point scale will be down the road. Nothing says it to be linear.
A: The mapping is defined by kNiceValues as stated above. The table is not linear, however linearity doesn't mean anything as it depends on the scheduler what the meaning of the values is, and usually only the order
comes into account, eg. a process is allways prefered with lower nice value as another independently how low it is. So the real effect is relative to all nice values used in the system and thus depending on the OS makers and all other app coders policies.
The android values have some named C constants suffixed like _NORMAL or
_URGENT_DISPLAY, pretending some meaning...
A: I would rely on thread.setPriority(). The android.os.Process.setThreadPriority names a real thread priority of the underliying linux OS. However, those could, but doesn't need to map to Dalvik / Java VM threads, as the VM could
do threading on its own means or use system threads or a combination of both. Raising the system priority would more likely result in prioritizing your application in favor of others, if not restricted by android security constraints, but not guarantee prioritizing
your current Java Thread in favor of other Java Threads in your application.
B: I don't know about that. Even on a modern unix machine, the java vm would make use of the native thread model. I have looked at the implementation of Process.setThreadPriority a little and yes it does
set the native thread priority directly in linux. However it just seems like it's almost a more granual approach since Thread.MAX_PRIORITY - Thread.MIN_PRIORITY is only distance ~10. To create a thread model that gets interleaved within the OS's seems like
it would be rather cumbersome and provide little benefit on an embedded device. I have to think there is more to it then what you suggest.