Doubt about Synchronized Code Clocks

[Spacen Jasset]

On 01/03/2011 16:59, d coder wrote:
>
>  > I'm afraid that I have no idea what would be "stale" about a shared
> variable.
>  > sychronized uses a mutex, and if you want to avoid race conditions,
> you need to
>  > use mutexes or something similar when dealing with shared variables.
> But I don't
>  > know what would be "stale" about a variable.
>  >
>
> One thread modifies a shared variable and the other thread still gets an
> old value. I do not know if this is applicable to D at all. Just wanted
> to get a clarification after I read an article in "Java Concurrency in
> Practice" book. I quote a relevant paragraph:
>
>     Locking is not just about mutual exclusion; it is also about memory
>     visibility. To ensure that all threads see the most up-to-date
>     values of shared mutable variables, the reading and writing must
>     synchronize on a common lock.
>
>
> Regards
Perhaps what you mean is synchronising a function vs shared data object.

If you have one Function A and some data D, then so long as ONLY 
function A (and it's callees) change or read D, then everything should 
work fine. Hence you're synchronising function A (or putting it in a 
critical section)


However, if you have two functions A and B, and data D. If function A 
and B can read and or write to the data D, then thread 1 can execute in 
A (but no other if it's synchronised) But, it may be pre-empted and 
another thread can then start executing in function B that is also 
synchronised. The problem here is that function A is half way though 
execution when B starts, hence you could likely have data in D that has 
been partially changed, "old" other otherwise inconsistent, which can 
cause problems, or even proper disasters.

The answer in this case is to have a mutex to protect D, so function A 
or B must obtain this and hold it while is modifies data D. Any other 
function will then have to wait for the mutex to be unlocked before 
reading or writing.