Wait_event_timeout kernel macro doubt - Unix

This is a discussion on Wait_event_timeout kernel macro doubt - Unix ; I've got a doubt about wait_event_timeout: DEFINE_WAIT() for(; { prepare_to_wait(); if(condition) break; ret=schedule_timeout(); if(!ret) break; } finish_wait(); if after prepare_to_wait but before the if statement the scheduler gets up and running (for example after an interrupt), is the caller process, ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Wait_event_timeout kernel macro doubt

  1. Wait_event_timeout kernel macro doubt

    I've got a doubt about wait_event_timeout:

    DEFINE_WAIT()
    for(;{
    prepare_to_wait();
    if(condition)
    break;
    ret=schedule_timeout();
    if(!ret)
    break;
    }
    finish_wait();

    if after prepare_to_wait but before the if statement the scheduler
    gets up and running (for example after an interrupt), is the caller
    process, at this point with state TASK_INTERRUPTIBLE or
    TASK_UNINTERRUPTIBLE, blocked untill someone calls wake_up? If so,
    wait_event_timeout is equal than wait_event. In addition, if the
    wake_up is called before prepare_to_wait and happends this case and
    the process was TASK_UNINTERRUPTIBLE, the process will spleep for
    ever. Am I saying a stupid thing?

    Thanks.

  2. Re: Wait_event_timeout kernel macro doubt

    On Jul 6, 11:46*am, Marco wrote:
    > I've got a doubt about wait_event_timeout:
    >
    > DEFINE_WAIT()
    > for(;{
    > * * * * prepare_to_wait();
    > * * * * if(condition)
    > * * * * * * * * break;
    > * * * * ret=schedule_timeout();
    > * * * * if(!ret)
    > * * * * * * * * break;}
    >
    > finish_wait();


    > if after prepare_to_wait but before the if statement the scheduler
    > gets up and running (for example after an interrupt), is the caller
    > process, at this point with state TASK_INTERRUPTIBLE or
    > TASK_UNINTERRUPTIBLE, blocked untill someone calls wake_up?


    If a task is involuntarily pre-empted, it must be restored. Only a
    task that is voluntarily pre-empted can be descheduled.

    > If so,
    > wait_event_timeout is equal than wait_event.


    It is a basic rule -- if you involuntarily pre-empt a task, that task
    is ready-to-run.

    > In addition, if the
    > wake_up is called before prepare_to_wait and happends this case and
    > the process was TASK_UNINTERRUPTIBLE, the process will spleep for
    > ever. Am I saying a stupid thing?


    The wake up cannot occur before the task is placed on a wait queue.
    The logic of the prepare_to_wait function is to atomically add the
    task to a wait a queue and change its state to blocked, then you check
    the event one last time before invoking the scheduler. That way, when
    the task invokes the scheduler, it will block if and only if the event
    did not occur while it wasn't looking.

    DS

  3. Re: Wait_event_timeout kernel macro doubt

    On 7 Lug, 01:04, David Schwartz wrote:
    > On Jul 6, 11:46*am, Marco wrote:
    >
    >
    >
    > > I've got a doubt about wait_event_timeout:

    >
    > > DEFINE_WAIT()
    > > for(;{
    > > * * * * prepare_to_wait();
    > > * * * * if(condition)
    > > * * * * * * * * break;
    > > * * * * ret=schedule_timeout();
    > > * * * * if(!ret)
    > > * * * * * * * * break;}

    >
    > > finish_wait();
    > > if after prepare_to_wait but before the if statement the scheduler
    > > gets up and running (for example after an interrupt), is the caller
    > > process, at this point with state TASK_INTERRUPTIBLE or
    > > TASK_UNINTERRUPTIBLE, blocked untill someone calls wake_up?

    >
    > If a task is involuntarily pre-empted, it must be restored. Only a
    > task that is voluntarily pre-empted can be descheduled.
    >
    > > If so,
    > > wait_event_timeout is equal than wait_event.

    >
    > It is a basic rule -- if you involuntarily pre-empt a task, that task
    > is ready-to-run.


    Ok.

    >
    > > In addition, if the
    > > wake_up is called before prepare_to_wait and happends this case and
    > > the process was TASK_UNINTERRUPTIBLE, the process will spleep for
    > > ever. Am I saying a stupid thing?

    >
    > The wake up cannot occur before the task is placed on a wait queue.
    > The logic of the prepare_to_wait function is to atomically add the
    > task to a wait a queue and change its state to blocked, then you check
    > the event one last time before invoking the scheduler. That way, when
    > the task invokes the scheduler, it will block if and only if the event
    > did not occur while it wasn't looking.
    >
    > DS


    I meant that for example if the wake_up is called inside an ISR and
    the interrupt occurs before the process calls prepare_to_wait(), I
    think it's possible, but if as you said my initial hypotesis is wrong
    then ok it's not a problem. Thanks for your response.

  4. Re: Wait_event_timeout kernel macro doubt

    Marco writes:
    > I've got a doubt about wait_event_timeout:
    >
    > DEFINE_WAIT()
    > for(;{
    > prepare_to_wait();
    > if(condition)
    > break;
    > ret=schedule_timeout();
    > if(!ret)
    > break;
    > }
    > finish_wait();


    [...]

    > if the wake_up is called before prepare_to_wait and happends this
    > case and the process was TASK_UNINTERRUPTIBLE, the process will spleep for
    > ever. Am I saying a stupid thing?


    Yes ;-). Assuming the wake_up was intended to wake this particular
    sleeper, the condition should be true when it is being tested and the
    thread will never go to sleep.


  5. Re: Wait_event_timeout kernel macro doubt

    On 7 Lug, 11:27, Rainer Weikusat wrote:
    > Marco writes:
    > > I've got a doubt about wait_event_timeout:

    >
    > > DEFINE_WAIT()
    > > for(;{
    > > prepare_to_wait();
    > > if(condition)
    > > break;
    > > ret=schedule_timeout();
    > > if(!ret)
    > > break;
    > > }
    > > finish_wait();

    >
    > [...]
    >
    > > if the wake_up is called before prepare_to_wait and happends this
    > > case and the process was TASK_UNINTERRUPTIBLE, the process will spleep for
    > > ever. Am I saying a stupid thing?

    >
    > Yes ;-). Assuming the wake_up was intended to wake this particular
    > sleeper, the condition should be true when it is being tested and the
    > thread will never go to sleep.


    Ok but this hypothesis was connected to the previous one, but if the
    previous is wrong then even that is wrong.

+ Reply to Thread