|
From: Bart V. A. <bar...@gm...> - 2006-08-27 15:26:46
|
On 8/27/06, Julian Seward <js...@ac...> wrote: > > > I have a wider question. I guess it is critical, for avoiding > false errors, that the tool sees all synchronisation points, else > it will be comparing segments that it should not compare, and so > may reporting false errors. Correct. So the question is: how do we know what subset of the pthread_ > functions is it necessary to intercept in order to make the tool > reasonably robust? I see you intercept a few .. > > create, join, mutex_init, mutex_destroy, mutex_lock, > mutex_unlock, mutex_trylock, cond_wait > > but surely there are a lot more that need to be intercepted? The following functions still have to be intercepted: pthread_mutex_trylock(), the rwlock family and the barrier-related functions. The last two families of functions are AFAIK not that frequently used. The following functions do not have to be intercepted: pthread_cond_signal(), pthread_cond_broadcast(). Now that we have a basic framework, how much of that pthread > intercept stuff can be imported from Diota (Diota is GPLd, right?) > DIOTA is indeed GPL'd. The drd code is not based on the DIOTA code however -- I started from the DIOTA papers. Implementing interception for the remaining synchronization functions is not that hard. |