I was experimenting with the concept of threading in java, we have a method setPriority, using which we can set thread priority. In official documentation it is given as below, enter image description here

But while seeing in actual execution, I observed something else, threads were executed normally as before without priority, on researching I found out that a thread will only run as per priority if there is a constraint with the system that is low memory, cpu, etc otherwise it will execute randomly since the system has no reason to stop other thread execution as we have ample amount of resources.

Having said that, I understood the context but what will happen if I have some real-time uses cases, where a delay of even milliseconds is not bearable? What is your understanding of it, how do I force priority-wise execution? Thanks in advance for sharing your wisdom :)

  • $\begingroup$ You get a real-time operating system, use a language that supports real-time operations and so on. $\endgroup$
    – gnasher729
    Mar 25, 2023 at 14:33

1 Answer 1


Operating systems don't always let a user control thread priority in the way that a programmer would like, and certainly not without extra privileges.

General-purpose operating systems have multiple classes of task priority. For example, you may find (in decreasing order of "priority"):

  • A few very high priority levels only accessible by the operating system itself (e.g. for kernel tasks or device drivers).
  • User-space real-time fixed-priority tasks.
  • User-space timeshared variable-priority tasks.
  • User-space low-priority tasks.
  • Idle tasks, which should only run when absolutely nothing else needs to run.

As well as priority (i.e. what should run), another thing that may be class-dependent is preemption. A system task would typically be non-preemptable, but a real-time task might be able to choose for itself whether or not it can be preempted.

A task would typically need permission to run in a higher-priority class. This is a security matter; if any task can decide itself to be non-preemptable, then any buggy or malicious task could take over the system and prevent, say, user interaction. You can imagine how malware might make use of this.

So this may be part of the answer to your question: Your task may not have permission to elevate its priority quite that far.

(Just to complicate things further, in microkernel and hybrid operating systems, some scheduling may occur outside the microkernel, and so a task might have different kinds of priority depending on who is doing it. This is the case in macOS, for example, and it's why a task has two separate priorities: the "Mach priority" and the "BSD priority". But I digress.)

A typical example of variable-priority timesharing scheduling is the Unix timesharing system, which might reserve 100 or so priority levels for user-space threads, and a thread's priority is determined by what it's doing. A thread which relinquishes the CPU because it is waiting for I/O, for example, will get a higher priority than one which exhausts its quantum.

The theory is that threads that wait tend to be more "interactive", so the system as a whole would feel more responsive if they got priority.

Within these constraints, a task can tell the operating system that it is more or less important/urgent, but that would typically be implemented as an adjustment on top of the timesharing scheduling system.

Exactly how the Java runtime implements thread priorities on top of the operating system is OS-dependent. Windows, for example, only has seven user priority levels, which is fewer than the Java API, and so the mapping will inevitably map some distinct Java priorities onto the same OS priority.

But even if there are a lot of priority levels available, the OS is free to interpret a thread priority however it wants. So this is possibly the other answer to your question: Even if your task has permission to elevate its priority to be real-time, the JDK may not provide a way to do it.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.