interruptible_sleep_on - Linux

This is a discussion on interruptible_sleep_on - Linux ; Hi there, I've two threads respectively used for reading from and writing to a device through device driver. In order to efficiently use the CPU resources, respected system-level read or write function has the ability to put the calling thread ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: interruptible_sleep_on

  1. interruptible_sleep_on

    Hi there,

    I've two threads respectively used for reading from and writing to a
    device through device driver. In order to efficiently use the CPU
    resources, respected system-level read or write function has the
    ability to put the calling thread to sleep. Here are my questions:

    For instance in the device driver code below, i) how do I know that the
    &ivm_wq_out is referring to the calling thread, READThread?

    Device driver:

    my_read(..)
    {
    if ( condition_true )
    interruptible_sleep_on(&my_wq_out);
    }

    similar, ii) how do I know that the &my_wq_in is referring to the
    calling thread, WRITEThread.
    my_write(..)
    {
    if ( condition_true )
    interruptible_sleep_on(&my_wq_in);
    }

    User application:

    READThread(void)
    {
    while(1)
    {
    ..
    read(fd, buf, len);
    ..

    }

    WRITEThread(void)
    {
    while(1)
    {
    ..
    write(fd, buf, len);
    ..

    }

    Thanks in advance. Very appreciate your comments.
    vib

    Reply


  2. Re: interruptible_sleep_on

    vib wrote:
    > Hi there,
    >
    > I've two threads respectively used for reading from and writing to a
    > device through device driver. In order to efficiently use the CPU
    > resources, respected system-level read or write function has the
    > ability to put the calling thread to sleep. Here are my questions:
    >
    > For instance in the device driver code below, i) how do I know that the
    > &ivm_wq_out is referring to the calling thread, READThread?
    >
    > Device driver:
    >
    > my_read(..)
    > {
    > if ( condition_true )
    > interruptible_sleep_on(&my_wq_out);
    > }


    Did you try reading the source code for interruptible_sleep_on?

    By the way, your above code has a nasty race condition. What if the
    condition becomes true after you test it, but before enqueuing to wait
    inside interruptible_sleep_on? Your thread will miss the wakeup and go
    to sleep on the queue.

    The above code can only work right if the wakeup comes only from
    another task, and not from interrupt context, and if both tasks hold
    the Big Kernel Lock.

    Did you say you wanted to make efficient use of CPU resources?

    > similar, ii) how do I know that the &my_wq_in is referring to the
    > calling thread, WRITEThread.
    > my_write(..)
    > {
    > if ( condition_true )
    > interruptible_sleep_on(&my_wq_in);
    > }


    This is exactly the same question, since this is almost the same piece
    of code, just with different names for the same pieces.


  3. Re: interruptible_sleep_on


    > Did you try reading the source code for interruptible_sleep_on?

    If I run out of options.
    >
    > By the way, your above code has a nasty race condition. What if the
    > condition becomes true after you test it, but before enqueuing to wait
    > inside interruptible_sleep_on? Your thread will miss the wakeup and go
    > to sleep on the queue.

    Yes, I know. That is why I want to balance out their processing time.
    >
    > The above code can only work right if the wakeup comes only from
    > another task, and not from interrupt context, and if both tasks hold
    > the Big Kernel Lock.

    Actually, the wakeup comes from the interrupt context. I can't see the
    problem of using interrupt context to wakeup either of the thread.
    Please enlighten me.
    >
    > Did you say you wanted to make efficient use of CPU resources?

    Yeah, within the context of these two thread. fyi, this a specific
    application device. So no other applications will run in this system.
    >



  4. Re: interruptible_sleep_on

    vib wrote:
    > > Did you try reading the source code for interruptible_sleep_on?

    > If I run out of options.


    You're kidding, right?

    > > By the way, your above code has a nasty race condition. What if the
    > > condition becomes true after you test it, but before enqueuing to wait
    > > inside interruptible_sleep_on? Your thread will miss the wakeup and go
    > > to sleep on the queue.

    > Yes, I know. That is why I want to balance out their processing time.


    In general, you don't fix race conditions by balancing processing time.

    > > The above code can only work right if the wakeup comes only from
    > > another task, and not from interrupt context, and if both tasks hold
    > > the Big Kernel Lock.


    > Actually, the wakeup comes from the interrupt context. I can't see the
    > problem of using interrupt context to wakeup either of the thread.
    > Please enlighten me.


    The problem is this:

    if (!condition)
    interruptible_sleep_on(...);

    The code which puts the thread on the wait queue and calls the
    scheduler is encapsulated within interruptible_sleep_on. So until some
    point of execution within interruptible_sleep_on, the calling task is
    not yet waiting. However, it has already checked the condition and
    found it to be false before entering into that function. If the
    interrupt comes in during this time window, it will set the condition
    true, but find nobody waiting. The task will go to sleep, even though
    the condition is true. This is called the ``lost wakeup problem''.


+ Reply to Thread