• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

[B]Class Monitor Vs. Object Monitor[/B]

 
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?





Result:

 
Ranch Hand
Posts: 443
3
Eclipse IDE C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Sree Va
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.



Result:
 
Ranch Hand
Posts: 208
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Chris Hurst
Ranch Hand
Posts: 443
3
Eclipse IDE C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ....

First of all I did this (XP2 SP2)

t1.start(); // sync
t2.start(); // sync
t3.start(); // static
t4.start(); // static

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)
 
reply
    Bookmark Topic Watch Topic
  • New Topic