aspose file tools*
The moose likes Threads and Synchronization and the fly likes doubt about 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 "doubt about "working memory"" Watch "doubt about "working memory"" New topic
Author

doubt about "working memory"

Leandro Oliveira
Ranch Hand

Joined: Nov 07, 2002
Posts: 298
I learned that working memory is a place where copy of variables from "main memory" are stored in, is this true??? (please correct me if I'm wrong). Does this work memory depends on synchronization??? I mean... without synchronization, there is no need of the working memory??? If the working memory exists with or without synchronization, when variables that must be reconciled with the main memory are reconciled??? exactly after a use or assign???

Thanks in advance!
raimondas zemaitis
Ranch Hand

Joined: Feb 23, 2001
Posts: 104
each thread has its own memory for operation and at some time moment data is flushed into main memory. This memory doesn't depend on synchronization and actually the purpose of syncronization is different - not to allow common data be changed in undefined way by separate threads. Look into JLS (Java Language Specification) for detailed explanations on how threads manage their memory.
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

Whenever a thread enters or exits a synchronized block, the variables within that synchronized block (which will all be in thread local memory) are reconciled with main memory. The memory in the thread is commonly referred to as "thread local memory."
raimondas zemaitis
Ranch Hand

Joined: Feb 23, 2001
Posts: 104
Originally posted by CL Gilbert:
Whenever a thread enters or exits a synchronized block, the variables within that synchronized block (which will all be in thread local memory) are reconciled with main memory. The memory in the thread is commonly referred to as "thread local memory."

This is very much wrong. Synchronization locks the object, it has no influence how threads deal with memory.
Below is piece of JLS about memory use:
<...>
An use or assign by T of V is permitted only when dictated by execution by T of the program according to the Java programming language's execution model. For example, an occurrence of V as an operand of the + operator requires that a single use action occur on V; an occurrence of V as the left-hand operand of the assignment operator = requires that a single assign action occur. All use and assign actions by a given thread must occur in the order specified by the program being executed by the thread. If the following rules forbid T to perform a required use as its next action, it may be necessary for T to perform a load first in order to make progress.
A store action by T on V must intervene between an assign by T of V and a subsequent load by T of V. (Less formally: a thread is not permitted to lose its most recent assign.)
An assign action by T on V must intervene between a load or store by T of V and a subsequent store by T of V. (Less formally: a thread is not permitted to write data from its working memory back to main memory for no reason.)
After a thread is created, it must perform an assign or load action on a variable before performing a use or store action on that variable. (Less formally: a new thread starts with an empty working memory.)
After a variable is created, every thread must perform an assign or load action on that variable before performing a use or store action on that variable. (Less formally: a new variable is created only in main memory and is not initially in any thread's working memory.)
Provided that all the constraints above and below are obeyed, a load or store action may be issued at any time by any thread on any variable, at the whim of the implementation.
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Originally posted by raimondas zemaitis:
This is very much wrong. Synchronization locks the object, it has no influence how threads deal with memory.
I don't mind ranchers correcting other ranchers on technical mistakes, but one would do well to carefully check the facts before doing so. The JLS, 17.6 Rules about the Interaction of Locks and Variables states:
Let T be any thread, let V be any variable, and let L be any lock. There are certain constraints on the actions performed by T with respect to V and L:
  • Between an assign action by T on V and a subsequent unlock action by T on L, a store action by T on V must intervene; moreover, the write action corresponding to that store must precede the unlock action, as seen by main memory. (Less formally: if a thread is to perform an unlock action on any lock, it must first copy all assigned values in its working memory back out to main memory.)
  • Between a lock action by T on L and a subsequent use or store action by T on a variable V, an assign or load action on V must intervene; moreover, if it is a load action, then the read action corresponding to that load must follow the lock action, as seen by main memory. (Less formally: a lock action acts as if it flushes all variables from the thread's working memory; before use they must be assigned or loaded from main memory.)
  • It is evident that contrary to what you seem to suggest, locks definitely interact with the way threads have to synchronize with main memory. I believe this is what CLG referred to.
    Allen Holub has written a lucid article about this phenomenon back in 2001.
    - Peter
    raimondas zemaitis
    Ranch Hand

    Joined: Feb 23, 2001
    Posts: 104
    Good article, thanks.
    I admit that my reply seems incorrect. What I meant by my post was that you can't expect that variable will only be updated when thread releases lock, by thinking so, one might run into problems, if he(she) expects that some global variable remains unchanged while thread is running synchronized piece of code. Yes, upon relese of lock everything from thread's memory will be flushed out, but how many times this happened prior to lock release is JVM implementation dependant.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: doubt about "working memory"