Synchronization question

[David Holmes]

On 21/12/2011 5:48 PM, Lee Ming wrote:
> 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) ?

Yes. As long as all accesses are within code locked by the same lock.

> 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

openjdk lists are for discussion of development of the OpenJDK not about
how to program in Java. For concurrency related questions I recommend
Doug Lea's concurrency-interest mailing list:

http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
http://g.oswego.edu/dl/concurrency-interest/

David
-----
> 
> 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 al! 
> lowed
>  > 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 regar! ds
>  > >
>  > > Bhm