The thread that breaks Java myths is awakened by priority

When writing multithreaded code, multiple threads often wait for an event to occur. This occurs when multiple threads call the Wait method in the synchronization method or in a synchronization block waiting for the same object to be locked. These wait threads are awakened when another thread that locks the object calls the Notify or Notifyall method from the synchronization method or the synchronization block. The notify call wakes up only one thread, so if more than one thread is in the waiting state, there is no competition for the lock. On the other hand, the notifyall call wakes up all the waiting threads and creates competition, while only one thread can get the lock and the rest will be blocked.

When multiple threads are in a waiting state, the question is which thread will run when the Notify or Notifyall method is invoked? Many programmers incorrectly assume that there is a predefined sequence of how threads are awakened. Some of the threads considered to be high-priority are awakened first, and others may think that the thread that is waiting for the longest time is awakened first. Unfortunately, the above assumptions are wrong. In these cases, which thread is awakened is indeterminate, perhaps the highest priority thread, perhaps the longest thread waiting, but there is no guarantee.

The priority of a thread does not determine whether it is awakened (in the case of using the Notify method) or in the order of arousal in a multithreaded environment (in the case of using the Notifyall method). Therefore, you should never assume the wake sequence of threads. In addition, you should never make any assumptions about the thread scheduling in the preemption process. Thread scheduling is an implementation-related (implementation-dependent), and the scheduling mechanism of different platforms is different. If you want your program to be portable, you should not make such unwise assumptions.

In addition, the Notifyall and notify methods do not provide a definite order for the wake-up wait process, in particular in order to rely on the JVM, and Notifyall can guarantee nothing more than waking all the waiting threads. This situation can cause problems when you want to wake multiple threads in a particular order.

There are two ways to control the wake sequence of threads:

1. Use accurate wake mode

(Specific notification pattern)

2, using the real-time specification of the JVM (Rtsj,real-time Specification for Java) (translator Note: This should not be considered a good way, which increased the reliance on a particular JVM, breaking the portability)

The exact wake pattern was developed by Tom Cargill, detailing how to control the wake-up order of threads that call notify and Notifyall. This implementation is achieved by setting a separate lock on each thread that needs to be awakened together or each set of threads. A customizable notification order is reached by releasing a specific lock.

If implemented properly, the execution cost of this pattern is minimal. However, it is inevitable to increase the complexity of coding, but this complexity can be offset by the control you get, and if you need such control, you can consider implementing this pattern.

RTSJ changes the standard behavior of some Java semantics. One of these is to make sure that the waiting threads are sorted by priority. So when multiple threads are in the waiting state and call notify or Notifyall, the one with the highest priority executes first and the other waits.

Typically, this is not a recommended practice, except for real-time programming. There are several different compromises that allow Java to program in real time. One of the most important principles of creating a RTSJ is that timeliness is more important than the speed of execution!