[Prev][Next][Index][Thread]
Re: Re : CPU inheritance issue
> I thot that's how it works practically. Once all the threads queue up
> for a mutex to be released; all of these are waiting for the same
> event to occur. and as soon as the mutex is released all the threads
> waiting for this mutex go to the "Ready List". and the regular
> scheduling takes place. This may even result in some high priority
> thread which was not in the wait queue acquire the mutex before any
> others.
Looking at pthread_mutex_unlock in pthread_mutex.c, mutex ownership is
transfered directly to a waiting thread, if one exists. When
DEFAULT_SCHEDULER is defined, this thread is the highest priority thread
in the queue - otherwise it's just the first thread.
Then (still in pthread_mutex_unlock) all waiting threads are unblocked to
undo the donation chain, but I don't think it matters since the first
thread has already taken ownership of the mutex.
One easy workaround would be to provide mutexes that are "tied" to a
particular scheduler - the unlock operation could then exploit knowledge
about that scheduler to pick the proper thread to give the mutex to.
This would be a win if threads that share data are often using the same
scheduler.
BTW, my intent here is not just to throw stones - I'm doing hierarchical
scheduling work for my dissertation so I've been doing lots of thinking
about the various complications it causes.
> do correct me if i am wrong.
> can u give me pointers to the paper you are referring to.
It's the CPU Inheritance paper at
http://www.cs.utah.edu/flux/papers/index.html
John
--
John Regehr | regehr@virginia.edu | http://www.cs.virginia.edu/~jdr8d/
grad student | Department of Computer Science | University of Virginia
References: