|
From: Bart V. A. <bar...@gm...> - 2006-09-18 20:02:16
|
On 9/17/06, Julian Seward <js...@ac...> wrote: > > > > - Regarding locking from within vg_preloaded.c: equivalents for > > pthread_mutex_lock(), unlock(), init() and destroy() should be > sufficient. > > At least for locking, adding two client requests, test-and-set, and > yield-this-thread, would make it easy to implement locking completely > independently of the application's thread library. I volunteer to > hack it up for you. > > > Please note that pthread_cond_init(), destroy(), signal() and wait() > also > > should be made available in vg_preloaded.c -- see also the comment about > > busy waiting in the valgrind core patch for drd ( > > > http://home.scarlet.be/%7Ebvassche/drd/valgrind-6012-core-2006-08-27.patch > ) > > Noted. What primitives do we need to implement condition variables? > I never really understood them. The following is needed for implementing condition variables (pthread_cond_wait(), pthread_cond_signal() and pthread_cond_broadcast): - A list of threads that are waiting. Such a list can e.g. be implemented as a doubly linked list. Elements of that list do not have to be allocated dynamically -- while unconventional, these list elements can also be allocated on the stack of the waiting threads. In the implementation of condition variable operations, there is no need to lock this list before accessing it -- in order to avoid race conditions, a mutex must be associated with each condition variable. This mutex must be locked before calling pthread_cond_signal(), pthread_cond_broadcast() or pthread_cond_wait(). - The primitive "yield-this-thread". - The primitive "wake-up-thread", which wakes up one specified thread. - There is no state associated with condition variables -- pthread_cond_wait() wakes up exactly one thread if at least one thread is waiting, and pthread_cond_broadcast() wakes up all waiting threads. |