[Mono-bugs] [Bug 74639][Nor] Changed - instruction sync needed for atomic.h on ppc

bugzilla-daemon@bugzilla.ximian.com bugzilla-daemon@bugzilla.ximian.com
Tue, 19 Apr 2005 11:14:29 -0400 (EDT)


Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by mass@akuma.org.

http://bugzilla.ximian.com/show_bug.cgi?id=74639

--- shadow/74639	2005-04-19 07:37:14.000000000 -0400
+++ shadow/74639.tmp.27474	2005-04-19 11:14:29.000000000 -0400
@@ -75,6 +75,25 @@
 semantics. Whether the latter is the correct thing to do is not clear,
 since the interlocked API doesn't give such guarantees. Note, in fact,
 as the MemoryBarrier API was added even to win32 to be able to deal
 with this issue.
 Adding memory barriers everywhere may help to fix broken code, but it
 will also slowdown everything.
+
+------- Additional Comments From mass@akuma.org  2005-04-19 11:14 -------
+Sorry, the patch uploaded was unfortunately a previous version - my local version is up-
+to-date, but I am writing a series of tests (single-threaded semantics observed tests, 
+multithreaded stress tests). I can submit these separately if desired.
+
+I believe a full sync to memory ("sync" instruction) is not needed, as memory accessed 
+within the routine is via lwarx/stwcx. insns. Instead, isync is needed to prevent the 
+resulting value returned from all of the instructions from being predictively used, before 
+other memory-accessing routines finish within the Interlocked* functions.
+
+Memory Barrier semantics are only defined by Microsoft for the Itanium Family; for some 
+reason they do not define these semantics for x86.
+
+Admittedly, I have not written PPC atomicity code before, and this is a learning exercise for 
+me. The justification I have for not putting memory barriers -in front- of these routines is 
+only that a cursory verification against the latest linux kernel source did not reveal 
+problems on PPC, and they had a thread involving SMP ppc atomicity semantics in 
+February, resulting in the creation of a locking contract document.