2.4.6 possible problem

2.4.6 possible problem

[Alex Ivchenko]

Guys,

does anybody use interruptible_sleep_on_timeout(&wqhead, jiffies); under 2.4.6 ?
It seems that after this call sleeping process is never rescheduled again.
Am I doing something wrong in my driver?


<10716>
Knowing that wait queue was reorganized in 2.4 I declared queue head as:

static DECLARE_WAIT_QUEUE_HEAD(wqhead);

and then in ioctl routine

Re: 2.4.6 possible problem

[Richard B. Johnson]

On Tue, 17 Jul 2001, Alex Ivchenko wrote:

> Guys,
> 
> does anybody use interruptible_sleep_on_timeout(&wqhead, jiffies);
> under 2.4.6 ?
> It seems that after this call sleeping process is never rescheduled again.
> Am I doing something wrong in my driver?
> 
> 
> <10716>
> Knowing that wait queue was reorganized in 2.4 I declared queue head as:
> 
> static DECLARE_WAIT_QUEUE_HEAD(wqhead);
> 
> and then in ioctl routine
  ^^^^^^^^^^^^^^^^^^^^^^^^^ Hmm. Don't decare it again.

funct()
{
    size_t ticks;
    wait_queue_head_t wqhead;
    init_waitqueue_head(&wqhead);

    ticks = 1 * HZ;        /* For 1 second */
    while((ticks = interruptible_sleep_on_timeout(&wqhead, ticks)) > 0)
                  ;
}

That'd oughtta do it. You can skip the loop if you can stand a short
timeout.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: 2.4.6 possible problem

[Alex Ivchenko]

Well,

> funct()
> {
>     size_t ticks;
>     wait_queue_head_t wqhead;
>     init_waitqueue_head(&wqhead);
> 
>     ticks = 1 * HZ;        /* For 1 second */
>     while((ticks = interruptible_sleep_on_timeout(&wqhead, ticks)) > 0)
>                   ;
> }
Well, this works.

The question is: should I call init_waitqueue_head() every time I call
interruptible_sleep_on_timeout() or is it enough to call it once in init_module() ?

Another one: should I call wake_up_interruptible() to release pending request?


-- 
Regards,
Alex

--
Alex Ivchenko, Ph.D.
United Electronic Industries, Inc.
"The High-Performance Alternative (tm)"
--
10 Dexter Avenue
Watertown, Massachusetts 02472
Tel: (617) 924-1155 x 222 Fax: (617) 924-1441
http://www.ueidaq.com

Re: 2.4.6 possible problem

[Richard B. Johnson]

On Tue, 17 Jul 2001, Alex Ivchenko wrote:

> Well,
> 
> > funct()
> > {
> >     size_t ticks;
> >     wait_queue_head_t wqhead;
> >     init_waitqueue_head(&wqhead);
> > 
> >     ticks = 1 * HZ;        /* For 1 second */
> >     while((ticks = interruptible_sleep_on_timeout(&wqhead, ticks)) > 0)
> >                   ;
> > }
> Well, this works.

Good.

> 
> The question is: should I call init_waitqueue_head() every time I call
> interruptible_sleep_on_timeout() or is it enough to call it once in
> init_module() ?

Just once is fine.

> 
> Another one: should I call wake_up_interruptible() to
> release pending request?

Nope. If you got control back due to the timeout, it's done. You
have been awakened. If somebody else wants to wake up your sleeping
giant (like an interrupt), it calls wake_up_interruptible() with
the pointer to the wait-queue it wants to affect.

> --
> Alex Ivchenko, Ph.D.
> United Electronic Industries, Inc.
> "The High-Performance Alternative (tm)"
> --
> 10 Dexter Avenue
> Watertown, Massachusetts 02472
> Tel: (617) 924-1155 x 222 Fax: (617) 924-1441
> http://www.ueidaq.com
> 

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: 2.4.6 possible problem

[Linus Torvalds]

In article <Pine.LNX.3.95.1010717103652.1430A-100000@chaos.analogic.com>,
Richard B. Johnson <root@chaos.analogic.com> wrote:
>
>    ticks = 1 * HZ;        /* For 1 second */
>    while((ticks = interruptible_sleep_on_timeout(&wqhead, ticks)) > 0)
>                  ;

Don't do this.

Imagine what happens if a signal comes in and wakes you up? The signal
will continue to be pending, which will make your "sleep loop" be a busy
loop as you can never go to sleep interruptibly with a pending signal.

In short: if you have to wait for a certain time or for a certain event,
you MUST NOT USE a interruptible sleep.

If it is ok to return early due to signals or similar (which is nice -
you can allow people to kill the process), then you use an interruptible
sleep, but then you mustn't have the above kind of loop.

		Linus

Re: 2.4.6 possible problem

[Richard B. Johnson]

On Tue, 17 Jul 2001, Linus Torvalds wrote:

> In article <Pine.LNX.3.95.1010717103652.1430A-100000@chaos.analogic.com>,
> Richard B. Johnson <root@chaos.analogic.com> wrote:
> >
> >    ticks = 1 * HZ;        /* For 1 second */
> >    while((ticks = interruptible_sleep_on_timeout(&wqhead, ticks)) > 0)
> >                  ;
> 
> Don't do this.
> 
> Imagine what happens if a signal comes in and wakes you up? The signal
> will continue to be pending, which will make your "sleep loop" be a busy
> loop as you can never go to sleep interruptibly with a pending signal.
> 
> In short: if you have to wait for a certain time or for a certain event,
> you MUST NOT USE a interruptible sleep.
> 
> If it is ok to return early due to signals or similar (which is nice -
> you can allow people to kill the process), then you use an interruptible
> sleep, but then you mustn't have the above kind of loop.
> 
> 		Linus

Okay, then ../linux/drivers/net/8139too.c (line 2239) should be fixed
because that's where it came from.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: 2.4.6 possible problem

[Richard B. Johnson]

On Tue, 17 Jul 2001, Richard B. Johnson wrote:

> On Tue, 17 Jul 2001, Linus Torvalds wrote:
> 
> > In article <Pine.LNX.3.95.1010717103652.1430A-100000@chaos.analogic.com>,
> > Richard B. Johnson <root@chaos.analogic.com> wrote:
> > >
> > >    ticks = 1 * HZ;        /* For 1 second */
> > >    while((ticks = interruptible_sleep_on_timeout(&wqhead, ticks)) > 0)
> > >                  ;
> > 
> > Don't do this.
> > 
> > Imagine what happens if a signal comes in and wakes you up? The signal
> > will continue to be pending, which will make your "sleep loop" be a busy
> > loop as you can never go to sleep interruptibly with a pending signal.
> > 
> > In short: if you have to wait for a certain time or for a certain event,
> > you MUST NOT USE a interruptible sleep.
> > 
> > If it is ok to return early due to signals or similar (which is nice -
> > you can allow people to kill the process), then you use an interruptible
> > sleep, but then you mustn't have the above kind of loop.
> > 
> > 		Linus
> 
> Okay, then ../linux/drivers/net/8139too.c (line 2239) should be fixed
> because that's where it came from.
> 

I hate to answer my own questions, but the above may be correct if
the task doesn't stay in interruptible_sleep_on_timeout() if there
is a signal pending. If true, it will not loop forever because of
the test for signal_pending(current).


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: 2.4.6 possible problem

[Alex Ivchenko]

Dick,

"Richard B. Johnson" wrote:
> 
> On Tue, 17 Jul 2001, Linus Torvalds wrote:
> 
> > In article <Pine.LNX.3.95.1010717103652.1430A-100000@chaos.analogic.com>,
> > Richard B. Johnson <root@chaos.analogic.com> wrote:
> > >
> > >    ticks = 1 * HZ;        /* For 1 second */
> > >    while((ticks = interruptible_sleep_on_timeout(&wqhead, ticks)) > 0)
> > >                  ;
> >
> > Don't do this.
> >
> > Imagine what happens if a signal comes in and wakes you up? The signal
> > will continue to be pending, which will make your "sleep loop" be a busy
> > loop as you can never go to sleep interruptibly with a pending signal.

Sleep like this is useless in real code. You either want your ioctl to unblock
when event (or time-out) happens or use sleep function to make driver wait certain 
amount of time (if you need to access poorly-designed hardware).

Off-topic:

>     I was going to compile a list of innovations that could be
>     attributed to Microsoft. Once I realized that Ctrl-Alt-Del
>     was handled in the BIOS, I found that there aren't any.
Well, give 'em at least some credit for copycating :-)
As a system architect I would say a *good* copycating.

For example:

Win32 events (CreateEvent(), WaitForxxxObject()) are very useful things.
The whole reason I was asking my questions is because I want to emulate Win32-like
event mechanism it Linux driver. I wouldn't mind to have this mechanism built into
Linux kernel. 

Say, one of the user process threads calls:
ret = WaitForSingleObject(hObject, dwTimeoutms);
or
ret = WaitForMultipleObjects(nNumber, hObjects[], FALSE, dwTimeoutms);

and waits until time-out or one (or more) objects are set.

>From the driver side you call:
KeSetEvent(hNotifyEvent, (KPRIORITY)1, FALSE);
when you want to release object.

It's very useful.
For example, with our hardware I can have up to 16*4 = 64 totally separated 
subsystems. Each subsystem can fire event asynchronously. It's much easier to
control each subsystem in separate thread and Win32 events are very handy.

-- 
Regards,
Alex

--
Alex Ivchenko, Ph.D.
United Electronic Industries, Inc.
"The High-Performance Alternative (tm)"
--
10 Dexter Avenue
Watertown, Massachusetts 02472
Tel: (617) 924-1155 x 222 Fax: (617) 924-1441
http://www.ueidaq.com