Synchronization question

[Lee Ming]

Hi Holmes,

Thank you for your answer, I just like to clarify my question and your answer so far,

public void put(long n){
 try{
    lock.lock();
    obj.put(n);
 }
 finally { lock.unlock();}
 }
 }

The obj.put(n) statement may involve with other methods within object obj,
and those method may involve with other methods from object reference within
obj, and thus the call may create a stack of more than one method. During the
execution of the stack, some fields of object obj may change it values. For example
obj.wInfo which is of type WInfo will be affected by obj.put(n).

So your answer is subsequent accesses by other threads through the same lock
will be able to read the latest value of obj.wInfo which has been accessed by
put(long n) ?

Anyway, sorry for the inconvenient caused by sending the email to wrong mailing
list. Just wonder where I should make similar question to a mailing list of openjdk

Thank you and have a nice day,
Bhm


> Date: Wed, 21 Dec 2011 17:15:05 +1000
> From: david.holmes at oracle.com
> To: wonderer_101 at live.com
> CC: serviceability-dev at openjdk.java.net
> Subject: Re: Synchronization question
> 
> Not sure why you sent this to serviceability-dev as this has nothing to
> do with the JDK/JVM serviceability APIs
> 
> On 21/12/2011 4:32 PM, Lee Ming wrote:
> > Currently We are developing a system that requires a lot of usages of 
> > Java concurrency. There seem to be some
> > concurrent bugs in our system. Thus I just wonder about the following 
> > usage of lock
> > 
> > class Test{
> > private final PInfo obj = new PInfo();
> > private ReentrantLock lock = new ReentrantLock();
> > ...
> > 
> > public void put(long n){
> > try{
> > lock.lock();
> > obj.put(n);
> > }
> > finally { lock.unlock();}
> > }
> > }
> 
> First the lock.lock() should be outside of the try block. lock.lock()
> may throw OutOfMemoryError for example, then you'd try to unlock and
> trigger an IllegalMonitorStateException.
> 
> > The question is: does the *lock.lock()* statement will guarantee that 
> > subsequent methods stacks
> > which involved! with *obj.put(n)* will be synchronized ? that is to say, 
> > the fields of the object *obj
> > *will be read/write directly from main memory and never cache.
> 
> I don't quite understand your question but thinking about caches is the
> wrong way to think about this. The Java Memory Model defines the rules
> for visibility and ordering of variables. This impacts not only
> potential caching affects on a given piece of hardware but also allowed
> optimizations by a JIT. The use of a Lock not only provides mutual
> exclusion for all sections of code protected by the same lock (and by
> extension, mutual exclusion to data if all accesses occur within those
> sections of code) but also ensures visibility of state changes made by
> one thread, to another thread that acquires the same lock.
> 
> So the lock() in the above ensures that calls to put() are serialized
> for a given instance of Test. If there were a corresponding get() that
> also acquired the lock then it would ensure that the thread doing the
> get saw the updates made to the PInfo object via its put method. But if
> you access the PInfo objects outside of that lock then there are no
> guarantees as to what state you will see that PInfo in.
> 
> Hope that helps.
> 
> David Holmes
> ------------
> 
> > 
> > Thank you and regards
> > 
> > Bhm
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20111221/594fe686/attachment.html