The following is my effort to differentiate Thread Monitors and priorities between them. Is this sample code infering more than that?
This my effort is trying to answer an interview question. The question: In a class with two sync methods and one static method with sync code block, explain the monitors, priorities and dependencies?
We believe that every being is divine, is God. Every soul is a sun covered over with clouds of ignorance; the difference between soul and soul is owing to the difference in density of these layers of clouds. - Swami Vivekananda
The issue with the code is that the threads aren't in a real world scenario alive at the same time, by that I mean they complete so fast they are unlikely to see each other to block against other. You would be better putting some delays into the run methods of each thread and then you might get a better idea of what is going on.
As a quick example if I were an interviewer I might say ok I ran your code as you suggested and got the results you said but then I did this ...
and got this on my pc (discuss) ...
increment() : i = 1 methodStaticOne() methodStaticTwo() decrement() : i = 0
i.e. what I'm trying to check you realise is the threads aren't blocking in the way I think you intended and you a have a race condition in your code i.e. nothing stops t1 completing (actually regardless of locks but thats another issue). I couldn't tell if you understood this (which you may have done).
Again if I were you I would play with putting some significant delays into the run methods (without releasing the locks) and reorder the starts in the main and consider the different results. I think the example should at least be likely to block and then you can consider class vs object locks.
"Eagles may soar but weasels don't get sucked into jet engines" SCJP 1.6, SCWCD 1.4, SCJD 1.5,SCBCD 5
Joined: Jan 28, 2007
I introduced delay in each method and changed the calling sequence. In every different calling combination, the static method with sync code block executed first, then the object sync method, then again static method with sync code block, then the object sync method,....... like round robin. This happens on Win XP Prof sp2.
Joined: Apr 19, 2005
In a class with two sync methods and one static method with sync code block, explain the monitors, priorities and dependencies?
You may answer the question without looking at the code since how a thread getting to a running state is depended on many factors: OS, number of processors, processor scheduling, and on top of those, the JVM thread scheduling. Since priority is just a hint to a JVM scheduling, it may completely ignore your priority setting. That being said, if you run this class on different machines, you could get different results. The sync methods are locked by the object instance while the static methods are locked by the class. These two locks are totally independent. thread.start() transits the thread to RUNNABLE state. It's up to the OS scheduler and JVM scheduler to transit this thread from RUNNABLE state to RUNNING state.
Code wise I think you are missing something, all you are doing with your code is playing with race conditions, the JVM is probably never going to compare thread priorities (across the different lock types) its just down to which wakes up first ....
methodStaticOne() increment() : i = 1 methodStaticTwo() decrement() : i = 0
Notice a non static sync has just beaten a static sync in (not really) ...
Now you might say but a static always gets in first (Not actually predictable behaviour) ... but heres why !
the non class sync does something it does a i ++ so ...
in this case the second thread can (/might) out race the first thread as it has no i++ to do and it goes to sleep first and therefore wakes up first ...
Proof I remove the i++
and the none static just won the race (but it was a race) ..........
increment() : i = 0 methodStaticOne() decrement() : i = 0 methodStaticTwo()
The 'increment' thread won because it went to sleep first and therfore was due to wake up first (not a priority thing) when it wakes up it can then race the class lock thread into system.out.println vs system.out.format.
Note I got all sort of results running this code twice (your code as its stands is NOT predictable) i.e. just because it does the same on your machine everytime doesn't mean it is)