nice()
If response is required on the order of 100 ms, the default may be sufficient, but it may not should
there be a lot of contention for the CPU. In this case, simply raising the time-sharing class priority
of the LWP is probably sufficient. The UNIX system call nice() will do this for you. Basically
what nice() will do is add (or subtract) a fixed priority number to the level calculated by the
kernel for an LWP, effectively making the LWP in question more "important" and ensuring that it
gets the CPU when it wants it. In UNIX98, nice() is defined to act on the entire process. It is
entirely implementation dependent and only gives you some vague control. In any case, this
technique cannot be used with Java, as there is no way to bind a thread to any particular LWP.
Realtime LWPs
It's when you require response in the 2100 ms range that things get interesting. You will need to
put the LWP into the realtime scheduling class. You do all the typical realtime tricks--no
blocking system calls, probably no I/O,[10] no paging (you'll need to lock down all the memory that
your thread will use: functions, stack, data.), etc. ("Etc." means that there is plenty more involved
that we haven't thought about, but that you'd better. Realtime processing is a tricky thing; be very
careful!) Java does not have realtime scheduling classes.
[10]
For I/O, you'd typically set up the buffers in the realtime thread but then allow a normal thread to
execute the I/O call on those buffers.
Avoid Realtime
You might require a realtime thread when you have the undivided attention of a user and are doing
constant updating (e.g., mouse tracking, video or audio playback) or when you are doing machine
feedback and control (e.g., autonomous vehicle navigation, robotics). Other instances include
when you are doing realtime data collection with analysis.
You might think that you need a realtime thread, but don't, when you update displays with the
divided attention of a human being (if you're 100 ms late in seeing the latest from the stock ticker,
no big deal). Avoid using the realtime class if you possibly can.
Allocation Domains
POSIX recognizes the desire of some programmers for closer control over the scheduling of
LWPs onto CPUs. Unfortunately, there is little convergence on the methods of doing so by the
vendors, so there is little that POSIX can say about it. Basically, POSIX defines allocation
domains, which are sets of CPUs. The programmer then specifies that certain LWPs are allowed
to execute on the CPUs in the chosen domains. All of these functions are implementation specific.
Do allocation domains really gain you anything? In certain realtime applications, yes. Otherwise,
probably not. Our opinion is that you are more likely to bog your program down with excessive
complexity than to improve it if you use them in most programs. Java has no interface for
allocation domains.
Binding LWPs to Processors
It's often possible to ensure that a given LWP will always run on a selected processor. It's also
possible to ensure that a given LWP will run to the exclusion of all other LWPs in all processes by
putting it into the realtime class. Doing both effectively binds the processor to the LWP as long as
the LWP wants to run.
Search WWH :
