Synchronized method's block list implementation

Question

In an object with synchronized methods, the OS maintains the list of blocked objects waiting to enter synchronzied methods. For this reason, I'm guesing, the Java spec seems to state the selection of these blocked objects as "arbitrary."
I am trying to determine that there is no risk of stavation in this blocked pool of threads. For example, a FIFO implementation of the blocked-object list would guarantee that all objects eventually entered their appropriate synchronized method.
Does anyone know for certain what blocked object selection algorithm is present on a JVM running on a Win32 platform? On SunOS 5.6? I believe the former uses a priority-based, preemptive thread scheduling with a round-robin-style time quantum to prevent starvation. Not sure what the latter uses.
Any ideas? Thanks!
-Jeff Ishaq

Answer 1

In an object with synchronized methods, the OS
maintains the list of blocked objects waiting to enter
synchronzied methods. For this reason, I'm guesing,
the Java spec seems to state the selection of these
blocked objects as "arbitrary."
As a general rule, you can never depend on the underlying threading model. The trend is to use the native threading model but that is not guaranteed by the specification.
I am trying to determine that there is no risk of
stavation in this blocked pool of threads. For
example, a FIFO implementation of the blocked-object
list would guarantee that all objects eventually
entered their appropriate synchronized method.
When a thread attempts to acquire a lock, it only checks to see if another thread already holds the lock, and not if another thread is already waiting for the lock. Therefore you should always consider the possibility that starvation can occur.
Does anyone know for certain what blocked object
selection algorithm is present on a JVM running on a
Win32 platform? On SunOS 5.6? I believe the former
uses a priority-based, preemptive thread scheduling
with a round-robin-style time quantum to prevent
starvation. Not sure what the latter uses.
Again, you should avoid depending on the native threading model because the specification does not guarantee that the java threading model is going to behave the same way.
To guarantee that each thread can acquire the lock you will need to develop a lock that has a queue associated with it. When a thread attempts to acquire the lock it is placed in a queue waiting until it is the first element in the queue. When the thread releases the lock it removes itself from the queue and notifies the other threads that are waiting.
When using a queued lock you will not necessarily need to use the synchronized keyword on the method or block since the lock will take care of synchronization when a thread attempts to acquire the lock.