• Post Reply Bookmark Topic Watch Topic
  • New Topic

Synchronization order in JMM

 
Sergei Zhylinski
Ranch Hand
Posts: 86
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Everyone,

I have a question on synchronization order. The JLS says that a synchronization order is the total order over all of the synchronization actions(v-write/v-read, unlock/lock) of an execution. This article gives a sort of clarification: "This means given two synchronization actions, A and B, either A so⇝ B or B so⇝ A.". This is a totality axiom of the total order.

So may I say, that if a thread tries to read a volatile variable, and another thread tries to read different volatile variable, or the same variable (or obtain a lock on some monitor) at the same time as the first thread, they will fail to do it simultaneously, only one at a time?
 
Henry Wong
author
Sheriff
Posts: 22542
109
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sergey Zhylinsky wrote:
I have a question on synchronization order. The JLS says that a synchronization order is the total order over all of the synchronization actions(v-write/v-read, unlock/lock) of an execution. This article gives a sort of clarification: "This means given two synchronization actions, A and B, either A so⇝ B or B so⇝ A.". This is a totality axiom of the total order.

So may I say, that if a thread tries to read a volatile variable, and another thread tries to read different volatile variable, or the same variable (or obtain a lock on some monitor) at the same time as the first thread, they will fail to do it simultaneously, only one at a time?


In the case of two parallel reads of volatile variables, does it really matter? Does it matter which read happened first? Or if they actually happened simultaneously? There is no way to tell what happened -- as both variables just read from memory (or more likely, from the CPU cache).

In the case of two parallel writes of volatile variables ... well, remember that (for volatile variables) the write has to go through the CPU cache, and go to memory. It also should invalidate the cache lines for all the cores as it is writing. This means that even if two different cores, happen to write to the same memory, at the exact same cycle, they both have to wait until it gets to memory. And with the CPU cache, and with memory, I believe that in every case, the hardware just picks one. One core will get the write first, and the other core will have to take a delay (and write next)... also, that order should be preserved. Any other cores reading at this time, should see the exact same order.

In the case of two lock grabs... well, I don't know the exact implementation of Java synchronization, but it should be a CAS operation underneath. With all CPU hardware, the CAS op code is guaranteed to be atomic (across all cores), and I guess it is possible for the CAS to fail (the compare to fail). In that case, the synchronization will just wait for the lock to be free -- in other words, it just blocks.

Henry


 
Sergei Zhylinski
Ranch Hand
Posts: 86
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes. I should have asked about two volatile writes instead of two volatile reads instead. )

I wonder, why two volatile writes on a same variable don't fall into 'synchronized-with' relation, defined on a synchronization order? These two writes don't correspond to 'synchronized-with' relation on a synchronized order and, as I understand, don't ordered by 'happens-before' relation. So theoretically they may be performed in parallel and lead to data race. The definition of the data race condition states, that its reason is not only write operation followed by read operation.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!