Great work but i have a couple of clarifications about NBHM.
1. AFAIK modifications to x,y,z by thread t1 will be pushed to the main memory only when a volatile flag is written to. And will consequently be visible to thread t2 who checks the same volatile flag before checking x,y,z(assuming x,y,z are non volatile).
In the source i could see the volatile being read before usage of key or value. but could not see the volatile being written to after CASing key or value. Since the CAS that you are using does not fence it only CASes down only the address of key, value.
Where is this taken care of? or am i mistaken in my assumptions??
2. the only reason for you to use Unsafe is because weakCAS from atomic package fences.
Regards
Mohit
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm using sun.misc.Unsafe. It makes no guarantees about volatile ordering.
The JDK's implementation of java.util.concurrent.Atomic.* uses sun.misc.Unsafe. Hence the *implementation* cannot rely on any volatile guarantees - but it hands OUT guarantees. There is a weak version (no volatile fencing) and a strong version. Both use the same underlying call to sun.misc.Unsafe. Hence, in practice, the sun.misc.Unsafe version must provide volatile-like ordering guarantees. So I get my ordering that way.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Cliff,
Great work but i have a couple of clarifications about NBHM.
1. AFAIK modifications to x,y,z by thread t1 will be pushed to the main memory only when a volatile flag is written to. And will consequently be visible to thread t2 who checks the same volatile flag before checking x,y,z(assuming x,y,z are non volatile).
In the source i could see the volatile being read before usage of key or value. but could not see the volatile being written to after CASing key or value. Since the CAS that you are using does not fence it only CASes down only the address of key, value.
Where is this taken care of? or am i mistaken in my assumptions??
2. the only reason for you to use Unsafe is because weakCAS from atomic package fences.
Regards
Mohit
I'm using sun.misc.Unsafe. It makes no guarantees about volatile ordering.
The JDK's implementation of java.util.concurrent.Atomic.* uses sun.misc.Unsafe. Hence the *implementation* cannot rely on any volatile guarantees - but it hands OUT guarantees. There is a weak version (no volatile fencing) and a strong version. Both use the same underlying call to sun.misc.Unsafe. Hence, in practice, the sun.misc.Unsafe version must provide volatile-like ordering guarantees. So I get my ordering that way.