Re: [Valgrind-developers] Interesting pthreads testcase

[Doug R. <df...@nl...>]

On Mon, 2004-02-16 at 06:57, Jeremy Fitzhardinge wrote:
> On Sat, 2004-02-14 at 11:15, Doug Rabson wrote:
> > Still, this behaviour works 'correctly' on FreeBSD, Linux, Solaris and
> > probably most other pthreads implementations. This testcase is a
> > distillation of how they get their application to shutdown cleanly.
> > 
> > The main problem is that while it runs the signal handler, the thread
> > isn't in WaitCV state (so the pthread_cond_broadcast doesn't do
> > anything) but when the signal frame is popped, it goes right back to
> > sleep. Somehow I need to be able to tweak the saved thread state in the
> > signal frame (or something).
> 
> I think the problem is that Valgrind is conflating two levels of
> abstraction.  There's the core scheduler's notion of a thread being
> "running" or "blocked", and there's the pthreads library's view of what
> state the thread is in with respect to pthreads objects.  I assume that
> "real" pthreads blocks in a syscall whenever it can be interrupted by a
> signal, and the syscall restart stuff (or whatever) decides what to do
> if it has been interrupted, what the new state of the pthreads object
> is, etc.

I have about half an answer (which I haven't thought through) where the
actual state transition from WaitCV to Runnable is made by the scheduler
(i.e. in the context of the waiting thread) rather than by the
signaller. It would go something like this:

	If a thread is in WaitCV but has no associated_cv
		If associated_mx is not held
			lock associated_mx
			clear associated_mx
			state is Runnable
		else
			state is WaitMX

Then in release_N_threads_waiting_on_cond, just check the value of
associated_cv (not the thread state). It would simply clear the
associated_cv variable and leave the mutex manipulation to the
scheduler. It would mean being squeaky clean about nulling associated_cv
when not waiting on a cond but I think that is done already.

> 
> Which raises a question: what happens if a thread blocks in a CV, is
> interrupted by a signal, and the signal handler does a longjmp to
> somewhere else?  What state is the CV left in?

A silly one. FreeBSD's libc_r woule probably have the thread still on
the cond's queue from a quick look at the code.