|
From: Bart V. A. <bar...@gm...> - 2006-09-13 19:53:27
|
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. > |