[Xenomai] Qeustion about rtdm_event_timedwait

[Xenomai] Qeustion about rtdm_event_timedwait

[Andrey Nechypurenko]

Hi,

I am writing rtdm driver where I have irq handler which should unblock
driver's read() function when certain condition is met. Roughly, it is
a wheel encoder driver where irq handler decrements the counter and
should wake up the reader when the counter is 0.

To implement this type of synchronization between irq handler and
reader, I am using events. In particular, the driver's read function
gets blocked with rtdm_event_wait (_timedwait has the same behavior)
and irq handler calls rtdm_event_signal when necessary. At the
"client" side, there is just a normal C program calling
rt_dev_open/rt_dev_write/rt_dev_read from the main function to test
the driver.

The following fragment illustrates the base idea.

Driver:

rtdm_read(..)
{
  while(! condition_is_met)
    rtdm_event_wait(...);

  rtdm_safe_copy_to_user(...)
}

IRQ handler:

handler(...)
{
  if(some_condition)
    rtdm_event_signal(...)

  return handled;
}

What I am observing is that rtdm_event_wait() does *not* actually
waits but instead returns immediately. To make sure that this is the
case, I've changed the dirver function as following:

rtdm_read(..)
{
  while(! condition_is_met)
  {
    rtdm_printk("waiting\n");
    rtdm_event_wait(...);
    rtdm_task_sleep(100ms); // to keep the system responsive
  }

  rtdm_safe_copy_to_user(...)
}

This outputs a bunch of "waiting" strings until the condition is met
and while loop exits. It happens even if wheels are not rotating at
all, i.e. for sure no event_signal() is called.

So this is definitely not what I was expecting but I do not see any
mistakes in the logic presented above. I would highly appreciate if
someone experienced in this area can provide some suggestions.

Also I have to mention, that driver's read() function is registered as
*read_nrt* and .device_class = RTDM_CLASS_EXPERIMENTAL. While studying
the rt_serial driver which uses similar way to communicate between isr
and read/write functions, I realize that over there read/write
functions are registered as *read/write_rt*. My naive attempt just to
register my functions as _rt lead to the situation where they are not
invoked at all. As I understand, because my test "client" is not a
real-time process. So does it imply that to make
event_wait/event_signal to work, the "client" must also run Xenomai RT
task?

In fact, in the documentation for rtdm_event_wait(), the following is mentioned:
This service can be called from:
 * Kernel-based task
 * User-space task (RT)

I thought, that since I am in driver's read() function, the first
statement "Kernel-based task" is what I am doing and it should be OK.
Did I misunderstand this statement and actually need to run RT task in
the client too?

So it would be very helpful for me if someone please can comment on it.


Regards,
Andrey.

Re: [Xenomai] Qeustion about rtdm_event_timedwait

[Gilles Chanteperdrix]

On 10/01/2012 05:51 PM, Andrey Nechypurenko wrote:
> driver's read() function is registered as *read_nrt*

That is the problem.

> real-time process. So does it imply that to make
> event_wait/event_signal to work, the "client" must also run Xenomai RT
> task?

Yes

> 
> In fact, in the documentation for rtdm_event_wait(), the following is mentioned:
> This service can be called from:
>  * Kernel-based task
>  * User-space task (RT)
> 
> I thought, that since I am in driver's read() function, the first
> statement "Kernel-based task" is what I am doing and it should be OK.

"Kernel-based task" means RTDM (or Xenomai) kernel based task.

-- 
					    Gilles.

Re: [Xenomai] Qeustion about rtdm_event_timedwait

[Andrey Nechypurenko]

> On 10/01/2012 05:51 PM, Andrey Nechypurenko wrote:
>> driver's read() function is registered as *read_nrt*
>
> That is the problem.

Thank you Gilles!

Re: [Xenomai] Qeustion about rtdm_event_timedwait

[Gilles Chanteperdrix]

On 10/01/2012 06:01 PM, Andrey Nechypurenko wrote:
>> On 10/01/2012 05:51 PM, Andrey Nechypurenko wrote:
>>> driver's read() function is registered as *read_nrt*
>>
>> That is the problem.
> 
> Thank you Gilles!
> 

If you want to wake up a regular thread, you should signal an
rtdm_nrtsig in the interrupt handler, and the nrtsig handler wakes up
the linux thread using regular linux services such as wake_up(). But in
that case, of course, do not expect low latencies for this thread.

Also note that rtdm_event_wait works like a semaphore, not like a
condition variable: it has a counter, rtdm_event_wait will return
immediately as many times as rtdm_event_signal was called.

-- 
					    Gilles.

Re: [Xenomai] Qeustion about rtdm_event_timedwait

[Andrey Nechypurenko]

> If you want to wake up a regular thread, you should signal an
> rtdm_nrtsig in the interrupt handler, and the nrtsig handler wakes up
> the linux thread using regular linux services such as wake_up(). But in
> that case, of course, do not expect low latencies for this thread.
>
> Also note that rtdm_event_wait works like a semaphore, not like a
> condition variable: it has a counter, rtdm_event_wait will return
> immediately as many times as rtdm_event_signal was called.

Thanks for the hints. It is not really necessary, but also not a
problem for me to start rt process at the client side. So now I have
to decide what is the best strategy for my use case.

Thank you,
Andrey.

Re: [Xenomai] Qeustion about rtdm_event_timedwait

[Andrey Nechypurenko]

>> Also note that rtdm_event_wait works like a semaphore, not like a
>> condition variable: it has a counter, rtdm_event_wait will return
>> immediately as many times as rtdm_event_signal was called.

In this case event_pulse will be then the closest match to condition
variable. Right?

Re: [Xenomai] Qeustion about rtdm_event_timedwait

[Gilles Chanteperdrix]

On 10/01/2012 06:13 PM, Andrey Nechypurenko wrote:
>>> Also note that rtdm_event_wait works like a semaphore, not like a
>>> condition variable: it has a counter, rtdm_event_wait will return
>>> immediately as many times as rtdm_event_signal was called.
> 
> In this case event_pulse will be then the closest match to condition
> variable. Right?

Well, looking at the code, it is not right, rtdm_event_wait works like a
semaphore, but a binary semaphore. So, if rtdm_event_signal was called
before rtdm_event_wait, rtdm_event_wait will return immediately, but if
it was called several times, rtdm_event_wait will return immediately
only once.

rtdm_event_pulse unlocks all threads currently blocked in
rtdm_event_wait, but you are right, it works more like a condvar.

-- 
					    Gilles.