|
From: <sv...@va...> - 2009-07-28 20:22:32
|
Author: sewardj
Date: 2009-07-28 21:22:18 +0100 (Tue, 28 Jul 2009)
New Revision: 10650
Log:
Back out a small part of r10589 (the tick-after-recv thing). On
contemplation it seems like a bad idea.
Modified:
trunk/helgrind/libhb_core.c
Modified: trunk/helgrind/libhb_core.c
===================================================================
--- trunk/helgrind/libhb_core.c 2009-07-28 12:54:47 UTC (rev 10649)
+++ trunk/helgrind/libhb_core.c 2009-07-28 20:22:18 UTC (rev 10650)
@@ -5540,10 +5540,14 @@
thr->viR = VtsID__join2( thr->viR, so->viR );
VtsID__rcinc(thr->viR);
-// QQQ
-VtsID__rcdec(thr->viR);
-thr->viR = VtsID__tick( thr->viR, thr );
-VtsID__rcinc(thr->viR);
+ /* At one point (r10589) it seemed safest to tick the clocks for
+ the receiving thread after the join. But on reflection, I
+ wonder if that might cause it to 'overtake' constraints,
+ which could lead to missing races. So, back out that part of
+ r10589. */
+ //VtsID__rcdec(thr->viR);
+ //thr->viR = VtsID__tick( thr->viR, thr );
+ //VtsID__rcinc(thr->viR);
/* For a strong receive, we also advance the receiver's write
clock, which means the receive as a whole is essentially
@@ -5553,13 +5557,10 @@
thr->viW = VtsID__join2( thr->viW, so->viW );
VtsID__rcinc(thr->viW);
-
-// QQQ
-VtsID__rcdec(thr->viW);
-thr->viW = VtsID__tick( thr->viW, thr );
-VtsID__rcinc(thr->viW);
-
-
+ /* See comment just above, re r10589. */
+ //VtsID__rcdec(thr->viW);
+ //thr->viW = VtsID__tick( thr->viW, thr );
+ //VtsID__rcinc(thr->viW);
}
Filter__clear(thr->filter, "libhb_so_recv");
|