|
From: Julian S. <js...@ac...> - 2006-09-14 09:06:23
|
Sounds plausible, and I like the idea of not messing with the state
machine. So you are saying, if you had a client request
VG_USERREQ__GET_MY_THREADID, that is all you would need?
How would you do the locking for this data structure? Would you
use pthread_mutex_{lock,unlock}? Does anything break if you call
those from inside the wrappers for pthread_{create,join} ?
J
On Wednesday 13 September 2006 20:53, Bart Van Assche wrote:
> A proposal for storing the (pthread_t, ThreadId) relationship in such a way
> that the scheduler's state machine doesn't have to be modified:
> - Add a client request such that a thread can query it's ThreadId from
> client space.
> - Implement a thread-safe data structure in the client that allows each
> thread to store its own ThreadId (thread-local storage can't be used for
> this purpose since each thread can only access it's own thread-local
> storage, and not that of another thread).
> - After each call to pthread_create(), store the (pthread_t, ThreadId) of
> the newly created thread in the just described data structure (e.g. at the
> beginning of vg_thread_wrapper()). Only allow pthread_create() to return
> after the (pthread_t, ThreadId) info has been stored, in order to avoid
> race conditions.
> - In the wrapper of pthread_join(), before the actual call of
> pthread_join(), obtain the ThreadId of the joined thread from that data
> structure. Next, call the actual pthread_join() function and do the
> post-thread-join client request. Next, remove the (pthread_t, ThreadId)
> info from the same data structure.
> - For detached threads, remove the (pthread_t, ThreadId) info at the time
> the thread is detached (this is either at thread creation time or at the
> time pthread_detach() is called).
>
> On 8/26/06, Bart Van Assche <bar...@gm...> wrote:
> > Hello Julian,
> >
> > Regarding thread state: I commented out tst->status = VgTs_Empty in
> > the assembly code cited below because I moved it to another point
> > (m_scheduler.c, case VG_USERREQ__POST_PTHREAD_JOIN). The background of
> > this change is as follows:
> > - After the client finished calling pthread_join(), drd needs to know
> > both the thread IDs of the thread that called pthread_join() and the the
> > ID of the joined thread. Once pthread_join() finishes, the client knows
> > the identity of both threads, but both IDs are of type pthread_t.
> > - drd uses ThreadId's internally. Hence, I needed a way to map pthread_t
> > into ThreadId. I had two options for storing the translation data between
> > these two types of thread IDs: either in the Valgrind core or in the
> > client.
> >
> > - When storing the translation information between pthread_t and ThreadId
> > in Valgrind, this translation information must still be accessible at the
> > time VG_USERREQ__POST_PTHREAD_JOIN is handled. This is why I postponed
> > cleanup of the per-thread data in Valgrind.
> > - Another option is to store the relationship between pthread_t and
> > ThreadId in the client. I can't solve this with thread-local storage
> > since this information is no longer accessible once pthread_join()
> > completes
> > (pthread_key_create()/pthread_key_delete()/pthread_setspecific()/pthread_
> >getspecific()).
> >
> >
> > Note: this change breaks clone() calls that do not originate from
> > pthread_create(). This can be solved by initializing the pthread_t value
> > kept for threads created by raw clone() calls to zero, and by executing
> > the statement "movl %1, %0\n" conditionally (only for threads created by
> > raw clone() calls). I did not yet implement this byself because I'm not
> > that fluent in assembly language.
|