|
From: Bart V. A. <bar...@gm...> - 2009-05-30 11:15:26
|
On Sat, May 30, 2009 at 1:02 PM, Julian Seward <js...@ac...> wrote: > > Ok in principle, but some comments: > >> > Adding support for the ANNOTATE_*() macro's in drd/drd.h is probably >> > not too hard. I'll have a look at it. >> >> Implementation-wise you need to support Annotate*() functions, or >> rewrite ANNOTATE*() macro's using client requests and support those >> client requests. >> I find the approach with Annotate*() functions simpler to maintain. > > I prefer that the basic thing that is implemented and documented to > be the ANNOTATE_* macros, not the Annotate*() functions. The macros > can be implemented with just a header file, like the Memcheck macros. > The functions require shared objects etc and therefore create a > dependency on a new library (IIUC), which isn't desirable. > > There are a lot of these requests, which is a big overhead w.r.t. > verifying that the implementation is correct and keeping it correct. > Are they all really necessary? I wonder if you can implement these > using a smaller subset, based on the idea of sending an abstract message > between threads. > > Suppose you had a > > ANNOTATE_SENDTO_SYNC_OBJECT(address) and > ANNOTATE_RECVFROM_SYNC_OBJECT(address) > > which create a h-b edge through the sync object. How many of these > requests could be implemented using just those two? Implementing some of the ANNOTATE_* macro's using the above two macro's would limit the usefulness of a thread checker tool because no information is passed to the tool about the type of synchronization object that resides at 'address'. Hence the tool cannot check whether the synchronization object has been used properly. Furthermore, implementing the ANNOTATE_RWLOCK_REQUIRED() / ANNOTATE_RWLOCK_RELEASED() macro's using ANNOTATE_SENDTO_SYNC_OBJECT() / ANNOTATE_RECVFROM_SYNC_OBJECT() would require that the client tracks the set of threads that hold a reader lock. This is something that should not be done by the client but by the tool. Bart. |