 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / December 2005object entry queue
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 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. > [...] 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 >> [...] don't want to rely >> on the jvm's fair policy, but instead the order in which each thread [quoted text clipped - 5 lines] > 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 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 > 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 >>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 [quoted text clipped - 5 lines] > 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.  SignatureJohn Bollinger jobollin@indiana.edu > 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. Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation > [...] 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 > > > 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 [quoted text clipped - 7 lines] > > 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 > 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 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. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.