Doubt about Synchronized Code Clocks

[Spacen Jasset]

On 01/03/2011 22:52, Spacen Jasset wrote:
> 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.
>
>
See: http://www.digitalmars.com/d/2.0/statement.html#SynchronizedStatement

So you can EITHER use synchronised to mark a block of code for execution 
by one thread only.

OR if you provide it with an expression, you mark the block to be run 
only if an object is "unlocked", therin only one thread may accesses a 
bit shared of data.

AFAIK this very similar to java 
http://www.herongyang.com/Java/Synchronization-Support-in-Java-synchronized.html