Kaynağa Gözat

* added a readbarrier after acquiring a read or write lock on
TMultiReadExclusiveWriteSynchronizer, to ensure that out-of-order
execution cannot already perform some reads inside the critical section
before the lock has been acquired
- removed now unnecessary read barrier before releasing a read lock

git-svn-id: trunk@14820 -

Jonas Maebe 15 yıl önce
ebeveyn
işleme
2c477269d0
1 değiştirilmiş dosya ile 7 ekleme ve 5 silme
  1. 7 5
      rtl/objpas/sysutils/sysuthrd.inc

+ 7 - 5
rtl/objpas/sysutils/sysuthrd.inc

@@ -93,6 +93,10 @@ begin
         always first increase freadercount and then check fwritelocked }
       while (System.InterLockedExchangeAdd(freadercount,0)<>0) do
         RTLEventWaitFor(fwaitingwriterlock);
+
+      { Make sure that out-of-order execution cannot already perform reads
+        inside the critical section before the lock has been acquired }
+      ReadBarrier;
     end;
 
   { we have the writer lock, and all readers are gone }
@@ -150,6 +154,9 @@ begin
             fwritelocked }
           System.InterlockedIncrement(freadercount);
         end;
+      { Make sure that out-of-order execution cannot perform reads
+        inside the critical section before the lock has been acquired }
+      ReadBarrier;
     end;
 end;
 
@@ -160,11 +167,6 @@ begin
     under unix and hence the event routines may throw an error }
   if IsMultiThread then
     begin
-      { Make sure that all read operations have finished, so that none of those
-        can still be executed after a writer starts working and changes some
-        things }
-      ReadBarrier;
-
       { If no more readers, wake writer in the ready-queue if any. Since a writer
         always first atomically sets the fwritelocked and then atomically checks
         the freadercount, first modifying freadercount and then checking fwritelock