waiting on a condition

waiting on a condition

[Martijn Sipkema]

L.S.

I'd like to do something similar as can be done using a POSIX condition
variable in the kernel, i.e. wait for some condition to become true. The
pthread_cond_wait() function allows atomically unlocking a mutex and
waiting on a condition. I think I should do something like:
(the condition is updated from an interrupt handler)

disable interrupts
acquire spinlock
if condition not satisfied
    add task to wait queue
    set task to sleep
release spinlock
restore interrupts
schedule

Now, this will only work with preemption disabled within the critical
section. How would something like this be done whith preemption
enabled?


--ms

Re: waiting on a condition

[Neil Horman]

Martijn Sipkema wrote:
> L.S.
> 
> I'd like to do something similar as can be done using a POSIX condition
> variable in the kernel, i.e. wait for some condition to become true. The
> pthread_cond_wait() function allows atomically unlocking a mutex and
> waiting on a condition. I think I should do something like:
> (the condition is updated from an interrupt handler)
> 
> disable interrupts
> acquire spinlock
> if condition not satisfied
>     add task to wait queue
>     set task to sleep
> release spinlock
> restore interrupts
> schedule
> 
> Now, this will only work with preemption disabled within the critical
> section. How would something like this be done whith preemption
> enabled?
> 
you above algorithm seems rather prone to deadlock.  Everything else in 
the kernel does more or less this operation by using a wait queue and a 
call to schedule to make tasks sleep until an event is signaled with a 
call to one of the wake_up family of functions.  Then a spinlock is used 
  to protect any critical data regions in smp environments.  Search the 
kernel for calls to add_wait_queue and wake_up[_interruptible] for 
examples of how this is implemented.

HTH
Neil

> 
> --ms
> 
> 
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


-- 
/***************************************************
  *Neil Horman
  *Software Engineer
  *Red Hat, Inc.
  *nhorman@redhat.com
  *gpg keyid: 1024D / 0x92A74FA1
  *http://pgp.mit.edu
  ***************************************************/

Re: waiting on a condition

[Duncan Sands]

You may want to look at include/linux/completion.h

Ciao,

Duncan.

Re: waiting on a condition

[Peter W. Morreale]

Have you looked at the wait_event() family yet?       Adapting that 
methodolgy might
suit your needs.

I don't know much about preemption yet, however I suspect it would be a 
bug to allow
preemption while the spinlock was held.  In other words, you might need 
to do something like

disable preemption
spinlock
rc = condition
spin_unlock
enable preemption
if (rc)
...

In other words, perform the test on the condition outside of the 
critical region protected by the spin lock.

-PWM


Martijn Sipkema wrote:

>L.S.
>
>I'd like to do something similar as can be done using a POSIX condition
>variable in the kernel, i.e. wait for some condition to become true. The
>pthread_cond_wait() function allows atomically unlocking a mutex and
>waiting on a condition. I think I should do something like:
>(the condition is updated from an interrupt handler)
>
>disable interrupts
>acquire spinlock
>if condition not satisfied
>    add task to wait queue
>    set task to sleep
>release spinlock
>restore interrupts
>schedule
>
>Now, this will only work with preemption disabled within the critical
>section. How would something like this be done whith preemption
>enabled?
>
>
>--ms
>
>
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>  
>

-- 
Peter W. Morreale                            email: morreale@radiantdata.com
Director of Engineering                      Niwot, Colorado, USA
Radiant Data Corporation                     voice: (303) 652-0870 x108 
-----------------------------------------------------------------------------
This transmission may contain information that is privileged, confidential
and/or exempt from disclosure under applicable law. If you are not the
intended recipient, you are hereby notified that any disclosure, copying,
distribution, or use of the information contained herein (including any
reliance thereon) is STRICTLY PROHIBITED. If you received this transmission
in error, please immediately contact the sender and destroy the material in
its entirety, whether in electronic or hard copy format. Thank you.

Re: waiting on a condition

[Martijn Sipkema]

On Wed, 2004-10-13 at 17:30, Peter W. Morreale wrote:
> Have you looked at the wait_event() family yet?       Adapting that 
> methodolgy might
> suit your needs.

wait_event() seems to be what I was looking for; I don't really like the
condition being an argument.

> I don't know much about preemption yet, however I suspect it would be a 
> bug to allow
> preemption while the spinlock was held.  In other words, you might need 
> to do something like
> 
> disable preemption
> spinlock
> rc = condition
> spin_unlock
> enable preemption
> if (rc)
> ...
> 
> In other words, perform the test on the condition outside of the 
> critical region protected by the spin lock.

Well, that wasn't what I meant exactly. I was looking for a standard
way to wait on a condition so that it would still work when spinlocks
are converted to mutexes such as these new RT patches seem to do;
wait_event() seens to provide this, although I like to POSIX mutex/cond
semantics better.


--ms


P.S. I seem to have been removed from the LKML right after posting
my question (it was the last message I received). Is there something
terribly stupid I may have done? Was the question _that_ stupid?



> -PWM
> 
> 
> Martijn Sipkema wrote:
> 
> >L.S.
> >
> >I'd like to do something similar as can be done using a POSIX condition
> >variable in the kernel, i.e. wait for some condition to become true. The
> >pthread_cond_wait() function allows atomically unlocking a mutex and
> >waiting on a condition. I think I should do something like:
> >(the condition is updated from an interrupt handler)
> >
> >disable interrupts
> >acquire spinlock
> >if condition not satisfied
> >    add task to wait queue
> >    set task to sleep
> >release spinlock
> >restore interrupts
> >schedule
> >
> >Now, this will only work with preemption disabled within the critical
> >section. How would something like this be done whith preemption
> >enabled?
> >
> >
> >--ms
> >
> >
> >
> >
> >-
> >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> >the body of a message to majordomo@vger.kernel.org
> >More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >Please read the FAQ at  http://www.tux.org/lkml/
> >
> >  
> >

Re: waiting on a condition

[Martijn Sipkema]

On Wed, 2004-10-13 at 17:30, Peter W. Morreale wrote:
> Have you looked at the wait_event() family yet?       Adapting that 
> methodolgy might
> suit your needs.

wait_event() seems to be what I was looking for; I don't really like the
condition being an argument.

> I don't know much about preemption yet, however I suspect it would be a 
> bug to allow
> preemption while the spinlock was held.  In other words, you might need 
> to do something like
> 
> disable preemption
> spinlock
> rc = condition
> spin_unlock
> enable preemption
> if (rc)
> ...
> 
> In other words, perform the test on the condition outside of the 
> critical region protected by the spin lock.

Well, that wasn't what I meant exactly. I was looking for a standard
way to wait on a condition so that it would still work when spinlocks
are converted to mutexes such as these new RT patches seem to do;
wait_event() seens to provide this, although I like to POSIX mutex/cond
semantics better.


--ms


P.S. I seem to have been removed from the LKML right after posting
my question (it was the last message I received). Is there something
terribly stupid I may have done? Was the question _that_ stupid?



> -PWM
> 
> 
> Martijn Sipkema wrote:
> 
> >L.S.
> >
> >I'd like to do something similar as can be done using a POSIX condition
> >variable in the kernel, i.e. wait for some condition to become true. The
> >pthread_cond_wait() function allows atomically unlocking a mutex and
> >waiting on a condition. I think I should do something like:
> >(the condition is updated from an interrupt handler)
> >
> >disable interrupts
> >acquire spinlock
> >if condition not satisfied
> >    add task to wait queue
> >    set task to sleep
> >release spinlock
> >restore interrupts
> >schedule
> >
> >Now, this will only work with preemption disabled within the critical
> >section. How would something like this be done whith preemption
> >enabled?
> >
> >
> >--ms
> >
> >
> >
> >
> >-
> >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> >the body of a message to majordomo@vger.kernel.org
> >More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >Please read the FAQ at  http://www.tux.org/lkml/
> >
> >  
> >

Re: waiting on a condition

[Davide Rossetti]

Martijn Sipkema wrote:

>On Wed, 2004-10-13 at 17:30, Peter W. Morreale wrote:
>  
>
>>Have you looked at the wait_event() family yet?       Adapting that 
>>methodolgy might
>>suit your needs.
>>    
>>
>
>wait_event() seems to be what I was looking for; I don't really like the
>condition being an argument.
>
>  
>
you may have a look at http://lwn.net/Articles/22913/
it's interesting :)
regards

Re: waiting on a condition

[Richard B. Johnson]

On Thu, 14 Oct 2004, Davide Rossetti wrote:

> Martijn Sipkema wrote:
>
> >On Wed, 2004-10-13 at 17:30, Peter W. Morreale wrote:
> >
> >
> >>Have you looked at the wait_event() family yet?       Adapting that
> >>methodolgy might
> >>suit your needs.
> >>
> >>
> >
> >wait_event() seems to be what I was looking for; I don't really like the
> >condition being an argument.
> >
> >
> >
> you may have a look at http://lwn.net/Articles/22913/
> it's interesting :)
> regards


You could always do:

	while(whatever)
        {
             set_current_state(TASK_INTERRUPTIBLE);
             schedule_timeout(0);
             if(signal_pending(current))
                 break;        // Or do something else
        }
        set_current_state(TASK_RUNNING); // Probably redundant

You could also set a specific HZ for the timeout, and count
them for a "never happened" timeout.




Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: waiting on a condition

[Alan Cox]

On Mer, 2004-10-13 at 21:58, Martijn Sipkema wrote:
> wait_event() seems to be what I was looking for; I don't really like the
> condition being an argument.

If you look at how it unwraps it is quite hard to do any other way.
You can always pass   myfunction() as the condition which is what I do
in for example the new tty code.

Re: waiting on a condition

[Christophe Saout]

[-- Attachment #1: Type: text/plain, Size: 599 bytes --]

Am Mittwoch, den 13.10.2004, 16:23 +0100 schrieb Martijn Sipkema:

> I'd like to do something similar as can be done using a POSIX condition
> variable in the kernel, i.e. wait for some condition to become true. The
> pthread_cond_wait() function allows atomically unlocking a mutex and
> waiting on a condition. I think I should do something like:
> (the condition is updated from an interrupt handler)

You can take a look at reiser4, it has such an implementation. It's
called kcond (fs/reiser4/kcond.c). It's using semaphores, waitqueues and
a spinlock to emulate POSIX conditions.


[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]