[luau] kicking a threads butt into action

William N Luoma luoma at hawaii.edu
Mon Jan 6 09:48:00 PST 2003


Charles,
thought about this some more.
what i said about trying to unlock a thread
locked by someone else is wrong wrt to spurious wakeups;
don't think it can happen.

when pthread_cond_wait returns,
the mutex is returned locked by the
thread that called pthread_cond_wait, 
whether or not the wakeup was spurious.
nevertheless, it is a good practice
to wait in a while loop.
Bill

----- Original Message -----
From: Bill Luoma <luoma at hawaii.edu>
Date: Monday, January 6, 2003 8:08 am
Subject: Re: [luau] kicking a threads butt into action

> Hi Charles.
> 
> are you checking for spurious wakeups in your threads?
> (using a while loop and a custom flag like: 
> 
> pthread_mutex_lock(&t_lock);
> while (!t_cond_flag) {
>     err = pthread_cond_wait(&t_cond, &t_lock);
>     if (err) { whatever }
> }
> //do work
> t_cond_flag = 0;
> pthread_mutex_unlock(&t_lock);
> 
> if you're not checking for these "spurious" wakeups,
> pthread_cond_wait can return zero... but really not
> have gotten a signal. . . in which case it would try
> to unlock a mutex it didn't lock. 
> which would lead to very undefined behavior.
> not sure if this can happen with linux.
> the solaris man page warns about it,
> as does Stevens.
> 
> Bill
> 
> ----- Original Message ----- 
> From: "Charles Lockhart" <lockhart at jeans.ifa.hawaii.edu>
> To: "LUAU" <luau at videl.ics.hawaii.edu>
> Sent: Sunday, January 05, 2003 8:07 AM
> Subject: [luau] kicking a threads butt into action
> 
> 
> > I've got an application that consists of three threads:
> > 
> > Thread 1 services a device on the PCI bus, basically reading 
> data from 
> > the device into buffers in memory.  After it's filled a buffer, 
> it calls 
> > pthread_cond_signal to start up thread 2, then it goes to sleep 
> for 
> > greater than a set period.  This thread seems to be working fine.
> > 
> > Thread 2, when woken up, confirms that the data in the buffers 
> is ready 
> > to process, processes the data into a different set of buffers, 
> calls 
> > pthread_cond_signal to wake up thread 3, checks to see if there 
> is any 
> > more work to be done, then if not, goes back to sleep.  This 
> thread also 
> > seems to be working fine.
> > 
> > Thread 3, when woken up, writes the data to a file, checks to 
> see if 
> > there's any more work to be done, if not goes back to sleep.  
> This 
> > thread is causing me problems.  Every once in a while it just 
> stops 
> > working.  I've verified that thread 2's calling of 
> pthread_cond_signal 
> > isn't returning an error.  Also, if I throw in printf's for 
> debugging 
> > (into thread 3), the problem seems to go away, though for some 
> reason I 
> > have this idea that maybe it just starts happening less often, 
> but that 
> > could be the paranoia talking.
> > 
> > So, like, this thread, thread 3, just up and quits doing 
> anything.  If 
> > it was just taking a long time to do the stuff, I could probably 
> figure 
> > it out, but it just seems to not be doing anything at all.  Do I 
> need to 
> > schedule this sucker myself, or what?  Anybody?
> > 
> > Uh, this is RH7.2, tested running both kernel 2.4.18-3 and 
> > 2.4.18-preemptive, the vanilla kernel with the RML preemptive patch.
> > 
> > Thanks,
> > 
> > -Charles
> > 
> > _______________________________________________
> > LUAU mailing list
> > LUAU at videl.ics.hawaii.edu
> > http://videl.ics.hawaii.edu/mailman/listinfo/luau
> _______________________________________________
> LUAU mailing list
> LUAU at videl.ics.hawaii.edu
> http://videl.ics.hawaii.edu/mailman/listinfo/luau
> 




More information about the LUAU mailing list