object entry queue

[anderson.wolfe]

does anybody know if the lock for an object is already owned: if
there's a way to enforce that the jvm always gives the lock to the
thread that's next up in the object's entry queue? i don't want to rely
on the jvm's fair policy, but instead the order in which each thread
was put in the entry queue.

thanks,
andy

 

[NullBock]

No restrictions are made on JVMs to give a lock to waiting objects in
any given order. It's a mistake to imagine that locks are given FIFO;
basically, you have to assume it's random.

Walter Gildersleeve
Freiburg, Germany

______________________________________________________
http://linkfrog.net
URL Shortening
Free and easy, small and green.

 

[Chris Uppal]

[...] don't want to rely
on the jvm's fair policy, but instead the order in which each thread
was put in the entry queue.

The (new in 1.5) java.util.concurent (or is ...rency ?) package includes
implementations of various IPC primitives that control fairness policy. If you
are not using 1.5, or if it doesn't provide something that fits your needs,
then you'll have to program it yourself using an explicit queue of some sort.

-- chris

 

[Robert Klemme]

[...] don't want to rely
on the jvm's fair policy, but instead the order in which each thread
was put in the entry queue.

The (new in 1.5) java.util.concurent (or is ...rency ?) package
includes implementations of various IPC primitives that control
fairness policy. If you are not using 1.5, or if it doesn't provide
something that fits your needs, then you'll have to program it
yourself using an explicit queue of some sort.

For pre 1.5 JVM he can use Doug Lea's implementation (which I believe is
just the basis for 1.5 functionality). See
http://gee.cs.oswego.edu/dl/

Apart from that, implementing a thread safe FIFO is not difficult either.

Kind regards

robert

 

[Robert Klemme]

does anybody know if the lock for an object is already owned: if
there's a way to enforce that the jvm always gives the lock to the
thread that's next up in the object's entry queue? i don't want to
rely on the jvm's fair policy, but instead the order in which each
thread was put in the entry queue.

What exactly do you need that for? Care to unveil a bit from the problem
you are trying to solve?

Kind regards

robert

 

[anderson.wolfe]

Thanks, Chris- exactly what I was looking for.
java.util.concurrent.locks.ReentrantLock has a fairness option in which
lock goes to the longest-waiting thread.

On a different note, for the specific case where there are only 2
threads, is it guaranteed that if one thread has the lock on an object
and the other thread is in the entry queue for that object (thus, the
only item in the entry queue), that when the lock is released the
thread in the queue will be the next to get the lock? In other words,
to guarantee the thread that originally has the lock cannot release it
and regain it before the thread in the queue has a chance to obtain the
lock?

andy

 

[anderson.wolfe]

hi robert- thanks for the help...i think the reentrantlock will work
for me. my question is mostly out of curiosity- im a student and i
originally was trying to optimize a selective repeat file transfer
protocol- where the threads to send packets and receive acks need to
share information about the base and sequence numbers. however,
enforcing this fairness would probably slow things because it maintains
locks without regards to the thread scheduling. so without the fairness
policy, if the base or seq. # is just off by one in a very occasional
circumstance, at worst 1 packet is retransmitted...shouldnt be a
problem.

 

[Chris Uppal]

On a different note, for the specific case where there are only 2
threads, is it guaranteed that if one thread has the lock on an object
and the other thread is in the entry queue for that object (thus, the
only item in the entry queue), that when the lock is released the
thread in the queue will be the next to get the lock?

I would assume so, in the absence of further information, but that assumption
should be validated by either reading the documentation carefully, or by
checking the source code (or both).

-- chris

 

[John C. Bollinger]

I would assume so, in the absence of further information, but that assumption
should be validated by either reading the documentation carefully, or by
checking the source code (or both).

I would assume not, though I haven't checked the specs on this.
Consider this code fragment:

synchronized (myObject) {
myObject.doSomethingWonderful();
}
synchronized (myObject) {
myObject.doSomethingTerrible();
}

Suppose thread A enters the first synchronized block, and thread B
blocks waiting for myObject's monitor. Thread A releases the monitor at
the end of the first block, and B is then eligible to acquire it, but B
does not necessarily run right away. Thread A is likely to attempt to
reacquire myObject's monitor before B next runs, in which case I don't
think it safe to assume that the VM will have already assigned ownership
of the monitor to B. If B has not yet run and the monitor is still
unassigned when A attempts to enter the second synchronized block, then
I don't see any reason to be confident as to which thread will get the
monitor next.

No amount of code inserted between the two blocks in the example
fundamentally changes the argument, though anything that blocks A is
likely to persuade the VM to let B run for a while, being assured of
obtaining the monitor because of lack of contention for it.

 

[Chris Smith]

I would assume not, though I haven't checked the specs on this.

In fact, John is correct. The specification makes no guarantees
whatsoever about the order of acquiring monitors. If a fair lock is
needed, one can be implemented on top of the basic monitor primitives.
For example, Java 1.5's ReentrantLock class takes a boolean parameter to
the constructor asking if it should be fair or not. The proposition
from earlier in this thread still doesn't hold, though, due to the
tryLock method. Another implementation of the 1.5 Lock class would need
to be devised to ensure that this proposition holds true.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris Uppal]

I would assume not, though I haven't checked the specs on this.

We seem to be thinking at cross-purposes. I was replying on the assumption
(unconsidered and quite possibly wrong) that Andy was asking about the locks in
the new concurrency stuff. If we are talking about the locks at the Java/JVM
level then indeed all bets are off.

(I note that Chris Smith believes that at least the new ReentrantLocks don't,
in fact, have the property in question. I haven't checked, but feel fairly
confident that he's right.)

-- chris

 

[Chris Uppal]

[...] Java 1.5's ReentrantLock class takes a boolean parameter to
the constructor asking if it should be fair or not. The proposition
from earlier in this thread still doesn't hold, though, due to the
tryLock method. Another implementation of the 1.5 Lock class would need
to be devised to ensure that this proposition holds true.

Or one could just refrain from using the tryLock() method.

-- chris