Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Static method and instance method locking  RSS feed

 
Shouvik Bhattacharya
Ranch Hand
Posts: 36
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok.. guys, this is again something I've been trying to do but its kinda not working....so here's the deal wait and notify are invoked on objects so things will get tricky if I try to call them from within static synchronized methods/blocks. But I want to do it just to see if that is even plausible or for that matter of fact a valid argument altogether.
I am putting down a simple producer consumer code...something that I've been trying to achieve dunno whether going in the right direction....




This thing stalls.....maybe I am doing something horribly wrong...but I am unable to achieve an interleaving behavior between the static method and the instance method......please guide me through.
 
Campbell Ritchie
Sheriff
Posts: 53750
127
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Please draw a diagram showing which methods are locked and what holds the lock. Remember that only an object can hold a lock; in the case of instance methods the default object is this and in the case of static methods it is the Class<T> instance which corresponds to the class you are using. In your example however, it would appear to be the same instance throughout.
I haven&pos;t done enough low level synchronisation to be able to say much more.

I shall copy both your threads to the threads forum.
 
Henry Wong
author
Sheriff
Posts: 22840
119
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

First, you have lots of issues with the code, but I can try address this one...

Shouvik Bhattacharya wrote:
This thing stalls.....maybe I am doing something horribly wrong


You consumer thread just tries to consume one value, and completes. So, your producer thread just waits (forever) for the consumer to consume more messages.

Henry
 
Shouvik Bhattacharya
Ranch Hand
Posts: 36
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Henry... After returning from the office I started debugging the previous code and accordingly carried out few changes. I just logged in to the ranch and walah! just read your reply which certainly corroborates my debugging efforts... Ya.. I made a silly mistake of not consuming the data to its entirety... So, now I am posting the changes I have done, would be great if you can point out the other flaws. And ya... just just to make sure we are on the same page I would like to reiterate the context that drove me to write the code in the first place which was that I wanted to have the threads communicate amongst each other between calls from a static method and a non static one as its kind of not possible to invoke wait or notify from a static context without some additional efforts. The code may not be a neat one but its working though

 
Henry Wong
author
Sheriff
Posts: 22840
119
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Shouvik Bhattacharya wrote:So, now I am posting the changes I have done, would be great if you can point out the other flaws.


Well, you seemed to have fixed many of the issues with your latest version, so, there are a less flaws. The remaining flaws are...

  • The inGet() method doesn't deal with spurious wakeups -- which is unlike the stSet() method that does via the while loop.
  • The getCount() method is not thread safe. It is accessing a variable that may be changed by another thread.
  • The consumer loop is not thread safe (when run with more than one consumer), as the getCount() method and the inGet() method calls are not atomic, between the while loop check, and the run during the body of the loop.

  • Henry
     
    Shouvik Bhattacharya
    Ranch Hand
    Posts: 36
    Eclipse IDE Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Henry....just made another round of changes based on the flaws you pointed out. I am posting the new changes would appreciate your feedback. Thanks

     
    Campbell Ritchie
    Sheriff
    Posts: 53750
    127
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Too difficult for “Beginning”. Moving both your threads entirely to the Threads forum.

    What are the changes you made? Please explain what you are doing.
     
    Shouvik Bhattacharya
    Ranch Hand
    Posts: 36
    Eclipse IDE Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Campbell Ritchie wrote:
    What are the changes you made? Please explain what you are doing.


    I was studying about inter-thread communication and as we are already aware that threads communicate amongst each other via wait and notify methods by securing a lock on the appropriate object. This is absolutely fine when one is working with instance methods as these are non static contexts and facilitate the developer to invoke the wait as well as the notify methods but lets take a use case where a communication has to be established between a static method and a non static method i.e. a class property and the other being an instance property. As far as the instance method is concerned it is fairly easy to invoke the wait and notify method but when talking about a static method we need a workaround as the same is readily unachievable. Through this thread I intended to know if my use case is at all a valid one and whether I am working in the right direction, if the motivation is correct then I wanted to illustrate this mechanism. Now, in order to get a better view of the entire flow I would request that you follow the code that I wrote at the beginning and gradually progress through the discussion that I had with Henry where he pointed out where I was doing it wrong. I tried to incorporate his suggestions and hopefully have got it right this time, just waiting for a final confirmation from him.

    Hope that helps...

     
    Henry Wong
    author
    Sheriff
    Posts: 22840
    119
    C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Shouvik Bhattacharya wrote:
    I was studying about inter-thread communication and as we are already aware that threads communicate amongst each other via wait and notify methods by securing a lock on the appropriate object. This is absolutely fine when one is working with instance methods as these are non static contexts and facilitate the developer to invoke the wait as well as the notify methods but lets take a use case where a communication has to be established between a static method and a non static method i.e. a class property and the other being an instance property. As far as the instance method is concerned it is fairly easy to invoke the wait and notify method but when talking about a static method we need a workaround as the same is readily unachievable.


    Since this code ... ... is equivalent to this code ...Technically, you can use the "MyClass.class" instance for the wait/notify mechanism. The JVM doesn't use this instance internally as a notification instance (nor is it likely to do so in the future), so it should be fine.

    Henry
     
    Shouvik Bhattacharya
    Ranch Hand
    Posts: 36
    Eclipse IDE Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hey thanks Henry... I wasn't aware of that. This discussion has been a great learning experience. So, I hope the last code I posted should be fine with respect to your previous suggestions?
     
    Henry Wong
    author
    Sheriff
    Posts: 22840
    119
    C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Shouvik Bhattacharya wrote:I hope the last code I posted should be fine with respect to your previous suggestions?


    A couple more ...

    Your SharedRes class methods takes a SharedRes instance. I am assuming that this is done in order to support more than one SharedRes instance, meaning having more than one separate groups of producers and consumers working independently. Otherwise, why do this? It can simply be a Singleton, without the need to have the SharedRes instance created externally, and passed in via method.

    However, this won't work. The way that it is coded, there can only be one SharedRes instance -- it must be a singleton.

    Your code uses the notifyAll() method. I understand why you are doing it, but I am *not* a fan of it. I would consider refactoring it to use the ReentrantLock class, and two Condition class instances (one for the producers and one for the consumers).

    Hope this helps,
    Henry

     
    Shouvik Bhattacharya
    Ranch Hand
    Posts: 36
    Eclipse IDE Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Henry Wong wrote:However, this won't work. The way that it is coded, there can only be one SharedRes instance -- it must be a singleton.

  • Okay.. I think I get this, since I am creating only a single instance of the SharedRes class in the main method you are suggesting it is better to change sharedRes to a singleton class instead of creating an instance. This, I suppose would look pretty neat from a design standpoint. I hope I have understood correctly?

  • Henry Wong wrote:Your SharedRes class methods takes a SharedRes instance. I am assuming that this is done in order to support more than one SharedRes instance, meaning having more than one separate groups of producers and consumers working independently. Otherwise, why do this?

  • Can you help me with a use case or an example where such a situation might come up. The only bit of thing I could come up with was where maybe one group of producer-consumer operate on a given state of the SharedRes class and the other group can start operating on SharedRes only after it achieves a state intended for the other group to work with. I could be wrong though...


  • Thanks
     
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!