At 9:53 AM -0800 2/12/01, Clifford Click wrote:
>Doug Lea wrote:
>> "Double-checked locking: Clever, but broken"
>> JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
>Yeah! A little more sanity in the world!
>Now on to my real reason for posting. I'm busy trying to make HotSpot
>safe for the new JMM and I'm staring at how we do synchronization. We
>use a CAS-style instruction on both Sparc and Intel; both are atomic
>unto themselves but neither make any multi-cpu guarentees. Do I need
>a multi-cpu guarentee at locks and unlocks? (assuming Sparc TSO and
>whatever passes for standard on multi-cpu intels). I afraid of what the
>performance hit will be when I insert a MEMBAR at each lock and unlock!
I looked at this previously.
By my understanding, unuder TSO, a CAS counts as a Read atomically
followed by a Write. None of the earlier memory references can be
reordered with the CAS-write, and none of the following memory
references can be reordered with the CAS-read.
So a CAS should act as a memory barrier, but we should get a Sparc
architect to verify this for us.
Intel IA-32 doesn't have a memory model (don't get me started on the
idiocy of a the major processor in use not having a memory model).
Each specific system built using IA-32 chips and other system chips
is allowed to have its own memory model.
I will try to work my contacts at Intel to see if I can't get some
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:30 EDT