Re: [Valgrind-developers] Valgrind and OpenMP

[Bart V. A. <bar...@gm...>]

On Wed, Oct 15, 2008 at 6:11 PM, Julian Seward <js...@ac...> wrote:
>> 2) Julian said that detecting locking primitives using only instructions
>> is too complex, maybe impossible. Well, but as far as I understood, you
>> are assuming a "general locking primitives detector". What if we limit
>> this problem only to the locking primitives present in the libgomp?
>> Would that be easier to do? (Of course it has a down side because every
>> time the libgomp changed, we would have to change Valgrind too... But I
>> think it's a valid question anyway)

[ ... ]

> From my brief investigation of the libgomp primitives, they are the same or
> similar to that which libpthread uses.  So a solution to libgomp would also
> allow us to see inside libpthread, which would be good.  But to be honest,
> overall I simply don't understand enough about the problem at this point to
> answer this question properly.

My opinion is that the extraction of information about locking
primitives from binary executables is a really powerful technique and
would be a very interesting addition to Valgrind. The big question
here is whether this is possible. This is at least a challenging
research topic.

In order to detect as much programming errors as possible, tools like
Helgrind and DRD discern a.o. the following primitives:
* atomic modifications of variables.
* mutex lock, unlock and trylock operations.
* semaphore post, wait and trywait operations.
* condition variables.
* reader-writer locks.
* barriers.

One issue that puzzles me is the following: it is possible to
implement a semaphore using one mutex and one condition variable, and
it is possible to implement a mutex using one semaphore. libpthread
implements semaphores, mutexes and condition variables via futexes. So
how is it possible by only analyzing futex calls and control flow
whether the (library) programmer has implemented a mutex or a
semaphore ?

Bart.