• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Exactly what in the thread local mem is synchronized on either side of a synch block

 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I have worked on a lot of multi-threading programs and I have a question which I havn't been able to find an answer for.

When before you enter a synchronization block, the local thread memory is updated from the "main memory" and when you leave a synchronization block the local thread memory is flushed back to the main memory keeping everyone happy.

But what *excatly* is flushed and is it implementation dependent.
1) Are all variables in the local thread flushed to main memory (ie all variables all the way up the stack).

2) Are all variables in the local thread memory at the top of the stack flushed?

3) Are only variables used within the synchrinization block in the current stack flushed?

I would love to know, since if 1) is the case, then I could probably remove some synchronized blocks which I have and optimise my code.
 
Bartender
Posts: 1638
IntelliJ IDE MySQL Database Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The answer to the question lies in the Java memory model.

Scotty But what *excatly* is flushed


The answer is that *whatever* is modified by the local thread is flushed to the main memory. So, the option is 1) i believe (if i understood your question correctly.)

Scottyis it implementation dependent


Java memory model is supposed to be followed by all the JVM implementations. So, it is *not* implementation dependent.

There is a catch in it though. The JMM only guarantees that the state of the objects will be consistent between two threads between the point a writing thread releases the lock on a monitor and reading thread acquires a lock on the *same* monitor.

So, if you have two threads working on different monitors but sharing the same data, then the data can be different as seen by two threads.

This article explains the gory details.
 
Scotty Boy Sinclair
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
ok thanks for the answer,

In essence, releasing a lock forces a flush of all writes from working memory employed by the thread, and acquiring a lock forces a (re)load of the values of accessible fields



interesting, I guess the reloading of accessable fields is deep, so the full object structure of a field would be reloaded??
 
Nitesh Kant
Bartender
Posts: 1638
IntelliJ IDE MySQL Database Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Scotty:
interesting, I guess the reloading of accessable fields is deep, so the full object structure of a field would be reloaded??



Well, for the JVM, it is a memory location and the value stored in that memory location.
So, it does not really matter whether the memory location is an object or a primitive type.
"Whatever" is stored in that location will be the latest -> This is the guarantee.

The point is that threads while processing a set of instructions copy the values stored at different memory locations in their working memory (Unaware of the fact that it is actually an object). JMM guarantees that the local cache is the latest in specific cases.

This sure will give you an impression that it is a deep copy but under the covers it's a simple memory address and its value.

Hope i answered your question.
reply
    Bookmark Topic Watch Topic
  • New Topic