aspose file tools*
The moose likes Threads and Synchronization and the fly likes Update of main memory copy after entering synchronized block Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Update of main memory copy after entering synchronized block" Watch "Update of main memory copy after entering synchronized block" New topic
Author

Update of main memory copy after entering synchronized block

Arthur Sc Chan
Greenhorn

Joined: Sep 07, 2010
Posts: 11
As I know, each thread will allows to keep its own working copy of the variables. And when it enter a synchronized block after obtaining the lock, it will also sync the working copy variable with the one in the main memory. But if the values is difference between the working copy of the thread and the copy in the main memory, what will java do actually?? Update the working copy with the values in the main memory or update the main memory values with the value in the working copy??
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Hi, Arthur, and welcome to the Ranch!

The memory model rules boil down to roughly:

1) The first read of any shared variable after entering a sync block must come from main mem (overwriting our copy).

2) Every shared variable that was changed must be written back to main mem before leaving the sync block (overwriting the main mem copy).

So, if your local copy is different than main mem, and you read that variable inside the sync block, then one of two things has happened: 1) Some other thread changed it, and you just hadn't got that update yet. Or 2) You changed it outside a sync block and it didn't get written back to main mem.

In the case of #2 you'll lose your local changes because they'll be overwritten by the value from main mem. However, this isn't a problem, because if you get to this state in the first place, you already have an earlier bug that needs to be fixed. Namely, you have previously changed a shared variable outside a sync block.
Arthur Sc Chan
Greenhorn

Joined: Sep 07, 2010
Posts: 11
Thanks Jeff for answering clearly. In addition to it, I want to know that in the sync block, is every value change in the share variable will write back to the main mem immediately, or it will only update the main mem just before it release the lock?? And if the value of another share variable has not changed in this sync block, will java try to update the value of it from the main mem??
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Arthur Sc Chan wrote:Thanks Jeff for answering clearly. In addition to it, I want to know that in the sync block, is every value change in the share variable will write back to the main mem immediately, or it will only update the main mem just before it release the lock??


The only requirement is that it has been written back to main mem by the time the lock is released. The implementation is free to do it immediately on write, or just before releasing the lock, or any time in between. If you do things correctly though, all access to the shared variables will be synced anyway, so your code will behave identically regardless of how the implementation does it. That's half the point of syncing in the first place, and the whole point of that rule.

And if the value of another share variable has not changed in this sync block, will java try to update the value of it from the main mem??


The only requirement here (I think) is that those values that are written while the lock is held be flushed to main mem before it's released. I don't think the spec cares if unchanged variables are written or not. In fact, I don't think it can care, since the way this gets implemented will generally include something like flushing an on-chip cache out to the real physical main mem of the computer. (Note that the "main mem" referred to so far is just the JVM's abstraction of the shared are vs. threads' local copies, independent of any particular implementation.) When that physical cache flush happens, I don't think the application (the JVM in this case) is able to say, "flush these values but not those."

But, again, like the first part, if you write your code correctly, it will behave the same regardless of which path the JVM chooses here.
Arthur Sc Chan
Greenhorn

Joined: Sep 07, 2010
Posts: 11
Thanks. Then am I correct that the following program can have a final result of t=3 or t=4 with uncertainty??


Also, now I understand that inside the sync block, all shared variable must ensure updating the main mem before leaving the block. then is it the case that "outside" of the sync block, the share variable will also have chance to update with the main mem, but no guarantee to it??
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Arthur Sc Chan wrote:Thanks. Then am I correct that the following program can have a final result of t=3 or t=4 with uncertainty??




Correct.


is it the case that "outside" of the sync block, the share variable will also have chance to update with the main mem, but no guarantee to it??


Correct.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40

Arthur Sc Chan wrote:Thanks Jeff for answering clearly. In addition to it, I want to know that in the sync block, is every value change in the share variable will write back to the main mem immediately, or it will only update the main mem just before it release the lock?? And if the value of another share variable has not changed in this sync block, will java try to update the value of it from the main mem??


This is, of course, a discussion on the specification. In practice, "dirty" variables (variables not written to main memory) are very short lived. And the word "immediately" is relative here -- as we are talking about time intervals that humans can't really directly perceive.

Variables are cached onto the processor registers. And there are very few of these registers. So... If the thread (running on the processor) makes a method call, it will likely write to memory. If the thread does I/O, it will definitely write back to memory. Actually, if the thread does anything that can cause a context switch, it will definitely write back to memory. If the processor needs to do an interrupt, which can happen thousands of times a second, it will write back to memory. etc.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
 
 
subject: Update of main memory copy after entering synchronized block