Back out a small part of r10589 (the tick-after-recv thing). On
contemplation it seems like a bad idea.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10650 a5019735-40e9-0310-863c-91ae7b9d1cf9
diff --git a/helgrind/libhb_core.c b/helgrind/libhb_core.c
index 58b5c6a..fab97ec 100644
--- a/helgrind/libhb_core.c
+++ b/helgrind/libhb_core.c
@@ -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");