aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Synchronization and lock question Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Synchronization and lock question" Watch "Synchronization and lock question" New topic
Author

Synchronization and lock question

David Samer
Ranch Hand

Joined: Feb 08, 2012
Posts: 49

Greetings everyone

Once again I am having some trouble understanding some concepts. From Kathy's and Bert's book (SJCP 6) , Chapter 9 - Threads- , pages 735, 736 and 737 . These are the things I do not get and would appreciate a practical example . (What a tough chapter)

First one: (Page 736)

A thread can acquire more than one lock. For example, a thread can enter a
synchronized method, thus acquiring a lock, and then immediately invoke
a synchronized method on a different object, thus acquiring that lock as
well. As the stack unwinds, locks are released again. Also, if a thread acquires
a lock and then attempts to call a synchronized method on that same
object, no problem.
The JVM knows that this thread already has the lock for
this object, so the thread is free to call other synchronized methods on the
same object, using the lock the thread already has.


:/ does anyone feel like writing a code example , please?.


Second one:

The way you can change a synchronized method to a synchronized code block: (Page 736 to 737 )

When you synchronize a method, the object used to invoke the method is the
object whose lock must be acquired. But when you synchronize a block of code, you
specify which object's lock you want to use as the lock, so you could, for example,
use some third-party object as the lock for this piece of code. That gives you the
ability to have more than one lock for code synchronization within a single object.
Or you can synchronize on the current instance (this) as in the code above.
Since that's the same instance that synchronized methods lock on, it means that
you could always replace a synchronized method with a non-synchronized
method containing a synchronized block. In other words, this:




is equivalent to this:




I have a feeling exam will be playing with this somehow way often than I think.

Basically , does it mean I can change synchronized method to just a synchronized block of code , in order to avoid (if necessary) get whole method synchronized.
Can we do this for any synchronized method?
Also, in that example, synchronized(this) ...looks like you are synchronizing "this" object rather than code block (and no idea how to determine which thread object would be the one holding the lock in this example) . Anyone can provide a better practical example?
I do understand lock as hmm kind of "state" perhaps?

Thank you in advance

Himai Minh
Ranch Hand

Joined: Jul 29, 2012
Posts: 812
    
    1
First answer:



Second answer:
Yes. Both doStuff() methods are the same. So , what is "this" refering to?

David Samer
Ranch Hand

Joined: Feb 08, 2012
Posts: 49

Hey, nice to see you around Himai ;)

Let's go with doubts!

In the first given example (thanks by the way) , which looks like :



b isn't released on second block finish? ( exactly in the curly brace after b.eat() in line 10 ).
Why both locks from both objects, a and b, gets released once first synchronized block finish?

As for the second example :



Clear example thanks.In this case, you are using an instance of the class itself (Demo) , in order to make it a Runnable target while using 2 threads. When t1 starts , and gets into run() method, if the other thread, t wants to start , it simply can't cause both are sharing Demo runnable instance? (So it gets t1 with lock) Assuming t1 is the first one which gets run method working.
Himai Minh
Ranch Hand

Joined: Jul 29, 2012
Posts: 812
    
    1
Hi, David,

1. To my knowlege, once the synchronized(b) block finishes, the lock of b is released.


2. Here is a possible case:
1) t1 starts and starts executing doStuff() method of the demo instance.
2) t starts and starts executing doStuff method of the same demo.
3) Since doStuff is invoked by demo and demo is locked by t1 in step 1, t1 prints 0...20.
4) t1 releases the demo's lock.
5) Now, it is the turn for t, which has been waiting for the lock of demo since step 2.
6) Since t1 has released demo's lock, t can lock demo now and print 0.....20.

Does it make sense?
David Samer
Ranch Hand

Joined: Feb 08, 2012
Posts: 49

Himai Minh wrote:Hi, David,

1. To my knowlege, once the synchronized(b) block finishes, the lock of b is released.



We agree then , confirmed My assumptions. Thanks.

Himai Minh wrote:

2. Here is a possible case:
1) t1 starts and starts executing doStuff() method of the demo instance.
2) t starts and starts executing doStuff method of the same demo.
3) Since doStuff is invoked by demo and demo is locked by t1 in step 1, t1 prints 0...20.
4) t1 releases the demo's lock.
5) Now, it is the turn for t, which has been waiting for the lock of demo since step 2.
6) Since t1 has released demo's lock, t can lock demo now and print 0.....20.

Does it make sense?


It does, clear explanation. I do appreciate it , thanks.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Synchronization and lock question