You know, it would help if I posted the right pseudocode.
Yes, I found this race condition a while ago. I do set flagvar _before_ I
chew on the hardware.
Nevertheless, what I'm seeing looks like either (a) the change to flagvar
isn't being propagated from the IRQ handler to the thread, or (b) the
down() fails to sleep for no good reason.
Matt
On Mon, Oct 16, 2000 at 05:34:02PM -0500, Sudhindra Herle wrote:
> You have a race condition.
>
> > int flagvar = 0;
> > struct semaphore blocking_sem;
> >
> > void function_called_from_kernel_thread(void)
> > {
> > chew_on_hardware();
> ^^^^^^^^^^^^^^^^^^^^^^^
> As soon as you do/did this, the IRQ must've happened. So, before the next
> statement is executed, the IRQ handler is called which clears flagvar.
>
> > flagvar = 1;
> This is executed _after_ the IRQ handler completes. So, you stomp over
> whatever
> the IRQ handler did.
>
> > down(blocking_sem);
> Since the IRQ handler did up(), this down() won't sleep.
>
> Try setting flagvar = 1 _before_ you chew_on_hardware().
> Make sure that what ever you do is SMP safe.
>
> Store the tick count of when you do the IRQ handler and when you do
> chew_on_hardware(). You'll see if I am right.
> i.e., try:
>
> before = system_ticks_NOW
> flagvar = 1;
> chew_on_hardware ();
> after = system_ticks_NOW
>
> printk (..., before, after, irq)
> ....
>
> interrupt_handler ( ..)
> {
> irq = system_ticks_NOW
> ...
> }
>
>
> Cheers,
> -Sudhi.
-- Matthew Dharm Home: mdharm-usb@one-eyed-alien.net Maintainer, Linux USB Mass Storage DriverDP: And judging from the scores, Stef has the sma... T: LET'S NOT GO THERE! -- Dust Puppy and Tanya User Friendly, 12/11/1997
This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:10 EST