|
From: Jeremy F. <je...@go...> - 2005-02-17 01:50:02
|
I'm checking in a work-in-progress snapshot of the pthread modelling
stuff. It handles thread creation, exit and join, and (non-recursive)
mutex operations. I've only tested it on little toy programs, nothing
real. The error reporting is just a stand-in.
This is just so people can get an idea of what I'm thinking, and with
luck, start jumping in when things are a little more stable. I'd like
to get this into working shape ASAP for the 2.4 release, so I think more
hands will help.
This is enabled with --model-pthreads=yes. Without that, none of this
code is ever called, and it should have no effect. That's why I'm not
worried about checking it in in this state.
There are two components: a thread model, and a libpthread binding for
the thread model. The thread model is almost completely abstract, and
has very little to do with the rest of Valgrind. It doesn't directly
interact with the concrete threads machinery at all.
The libpthread binding uses the wrapping machinery I checked in a while
ago to wrap calls to libthread, and generate a series of events for the
thread model.
TODO:
* do proper error reporting
* implement recursive mutexes
* implement condition variables
* implement rwlocks
* work out how to handle cancellation
* handle thread attributes
* handle mutex attributes
* test it against real programs/test suites
* fix helgrind
* make pthread-binding as implementation-neutral as possible
FUTURE TODO:
* implement (potential) deadlock detection (generate lock-ranking
graphs)
* handle the rest of libpthread (barriers, semaphores, etc)
* implement client callbacks for thread operations (for non-pthreads
private thread libraries)
* give thread model a separate abstract notion of a thread id
* handle N:1 and N:M thread models
J
|