JDK-4234402 : (thread) Thread.setCPUAffinity?
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 1.2.1,1.2.2,1.3.0,1.4.2,6
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic,windows_2000,windows_xp
  • CPU: generic,x86
  • Submitted: 1999-04-30
  • Updated: 2005-05-09
  • Resolved: 2005-05-09
Related Reports
Duplicate :  
Description

Name: vi73552			Date: 04/30/99


Could you please add to the system properties, an indication of how many processors the underlying system is using. For multi-threaded, CPU intensive applications, this can be useful information.
(Review ID: 57682) 
======================================================================

Name: rlT66838			Date: 08/31/99


The proposal is as follows:

1. Add method in class System:

int getNumCPUs(). It returns the number of CPUs, if the platform supports discovering the number of CPUs using some native system call or another, or else if the platform does not allow it, returns 1.

2. Add method in class Thread:

void setCPUAffinity(int id). It sets the thread to run on the identified CPU, numbered from 1 to the number returned by System.getNumCPUs; if you pass it 0 it sets the thread to the default behavior on the system, likely that the thread is moved around by the OS to balance load. If the id is bigger than the number of available CPUs it is reduced modulo the number of available CPUs. (This may be useful when spawning threads in a loop and trying to balance them or group them a certain way.) If the id is negative or the thread is dead, an illegalArgumentException is thrown.
This, of course, only applies if the platform has native threads and the native threads can be set on a specific CPU. Otherwise this is a no-op. It may be necessary to convert between a Java CPU-id and a platform-dependent number or handle.
The default CPU affinity for a thread will be 0.

3. (optional) Add method in class Thread:

int getCPUAffinity(). This returns the thread affinity value of the thread. So at the end of this method:

void myMethod (Thread aThread, int a) {
  aThread.setCPUAffinity(a);
  int b = aThread.getCPUAffinity();
}

it should be an identity that b == a unless a was out of range or the thread was no good (e.g. null or dead).


ALTERNATIVELY: The default affinity of a thread will be that of its threadgroup, the affinity of the main threadgroup will be 0 initially, threadgroups will have analogous methods to threads for CPU affinity (a threadgroup affinity change will affect threads with affinity 0 only, and a thread with affinity 0 inherits the threadgroup's affinity); a threadgroup with a parent and affinity 0 inherits the parent's affinity; and the affinities of things like the gc thread are implementation-dependent, and will probably either all be 0 or be chosen by the runtime startup to balance the load caused by the major daemon threads.
(Review ID: 94566)
======================================================================

Comments
EVALUATION madbot: another useful property in the sun.cpu family? anand.palaniswamy@Eng 1999-04-30 Use java.lang.Runtime.availableProcessors() for number of processors. I won't put this into a system property as the number can change during the lifetime of the VM (see method spec for details). Since we may still want to add setCPUAffinity in a future release, I am changing the synopsis to reflect the remaining issue here. ###@###.### 2002-06-13 Several years ago the proper behavior of the proposed method would have been pretty well understood on operating systems providing high levels of control over scheduling and it might have mapped fairly well to the predominate SMP designs of the time (emphasis on "Symmetric"). But this is ignoring the basic fact that only the most sophisticated Java users could expect to gain real advantage with such a feature (i.e. by making better scheduling choices than the operating system would make without use of the feature). Now, with the trend toward NUMA and the increasingly fuzzy definition of "CPU" with multicore processor designs (and the fuzziness is going to monotonically increase, at least for a few years) this method simply won't provide proper utility in return for the investment required to implement and maintain it. ###@###.### 2005-05-09 19:31:41 GMT
09-05-2005

WORK AROUND Name: vi73552 Date: 04/30/99 The O-Reilly Java Threads book has a JNI implementation. ====================================================================== Name: rlT66838 Date: 08/31/99 Hope the operating system's scheduler does a good job. And avoid using a Microsoft operating system :-) (Review ID: 94566) ======================================================================
08-09-2004