|
From: <sv...@va...> - 2011-03-11 18:38:21
|
Author: sewardj
Date: 2011-03-11 18:38:12 +0000 (Fri, 11 Mar 2011)
New Revision: 11624
Log:
Change the semantics of ANNOTATE_HAPPENS_BEFORE from 'overwrite' to
'add' behaviour, w.r.t. any h-b edges associated with the
synchronisation object prior to the call. This brings the behaviour
into line with DRD and TSan, and is required for correct annotation of
thread safe reference counting. It fixes #243935 -- at least, the
original bug as discussed in comments 0 and 2.
Modified:
trunk/helgrind/helgrind.h
trunk/helgrind/hg_main.c
Modified: trunk/helgrind/helgrind.h
===================================================================
--- trunk/helgrind/helgrind.h 2011-03-10 21:34:21 UTC (rev 11623)
+++ trunk/helgrind/helgrind.h 2011-03-11 18:38:12 UTC (rev 11624)
@@ -433,14 +433,16 @@
/* ----------------------------------------------------------------
Create completely arbitrary happens-before edges between threads.
- If thread T1 does ANNOTATE_HAPPENS_BEFORE(obj) and later (w.r.t.
- some notional global clock for the computation) thread T2 does
- ANNOTATE_HAPPENS_AFTER(obj), then Helgrind will regard all memory
- accesses done by T1 before the ..BEFORE.. call as happening-before
- all memory accesses done by T2 after the ..AFTER.. call. Hence
- Helgrind won't complain about races if T2's accesses afterwards are
- to the same locations as T1's accesses before.
+ If threads T1 .. Tn all do ANNOTATE_HAPPENS_BEFORE(obj) and later
+ (w.r.t. some notional global clock for the computation) thread Tm
+ does ANNOTATE_HAPPENS_AFTER(obj), then Helgrind will regard all
+ memory accesses done by T1 .. Tn before the ..BEFORE.. call as
+ happening-before all memory accesses done by Tm after the
+ ..AFTER.. call. Hence Helgrind won't complain about races if Tm's
+ accesses afterwards are to the same locations as accesses before by
+ any of T1 .. Tn.
+
OBJ is a machine word (unsigned long, or void*), is completely
arbitrary, and denotes the identity of some synchronisation object
you're modelling.
@@ -453,6 +455,9 @@
take the time to understand these two. They form the very essence
of describing arbitrary inter-thread synchronisation events to
Helgrind. You can get a long way just with them alone.
+
+ See also, extensive discussion on semantics of this in
+ https://bugs.kde.org/show_bug.cgi?id=243935
----------------------------------------------------------------
*/
#define ANNOTATE_HAPPENS_BEFORE(obj) \
Modified: trunk/helgrind/hg_main.c
===================================================================
--- trunk/helgrind/hg_main.c 2011-03-10 21:34:21 UTC (rev 11623)
+++ trunk/helgrind/hg_main.c 2011-03-11 18:38:12 UTC (rev 11624)
@@ -3040,9 +3040,12 @@
/* TID is just about to notionally sent a message on a notional
abstract synchronisation object whose identity is given by
USERTAG. Bind USERTAG to a real SO if it is not already so
- bound, and do a 'strong send' on the SO. This is later used by
+ bound, and do a 'weak send' on the SO. This joins the vector
+ clocks from this thread into any vector clocks already present
+ in the SO. The resulting SO vector clocks are later used by
other thread(s) which successfully 'receive' from the SO,
- thereby acquiring a dependency on this signalling event. */
+ thereby acquiring a dependency on all the events that have
+ previously signalled on this SO. */
Thread* thr;
SO* so;
@@ -3056,7 +3059,7 @@
so = map_usertag_to_SO_lookup_or_alloc( usertag );
tl_assert(so);
- libhb_so_send( thr->hbthr, so, True/*strong_send*/ );
+ libhb_so_send( thr->hbthr, so, False/*!strong_send*/ );
}
static
|