[Xenomai-help] Strange behaviour w/mutex&semaphore

[Xenomai-help] Strange behaviour w/mutex&semaphore

[ROSSIER Daniel]

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


Hi all,

I've a strange behaviour with the attached piece of code.
It's really simple: there are 3 tasks and we're spinning within the task in order
to simulate task load.

It's a pure academic exercice, so don't try to think about the usefulness of this code ;-)


Actually, after insmod'ing the code into the kernel, the system freezes and
the "meteoDataAcquisition" task is suspended runaway by the internal xenomai watchdog.

Why?

Anything wrong in this code?

Thanks for any advice.

Daniel


[-- Attachment #2: mytry.c --]
[-- Type: application/octet-stream, Size: 2878 bytes --]



#include <linux/module.h>
#include <native/task.h>
#include <native/sem.h>
#include <native/mutex.h>
#include <native/alarm.h>

#define STACK_SIZE 8192
#define MS 1000000 

#define WITH_MUTEX  1  /* semaphore/mutex selection */

RT_TASK busManagementTask;
RT_TASK meteoDataAcquisitionTask;
RT_TASK comHandlingTask;

RT_SEM sema;
RT_MUTEX mutex;

int err;

void meteoDataAcquisition(void *cookie) {

  while(1) {

    if (WITH_MUTEX)
      rt_mutex_lock(&mutex, TM_INFINITE);
    else
      rt_sem_p(&sema, TM_INFINITE);

    rt_timer_spin(10*MS);

    if (WITH_MUTEX)
      rt_mutex_unlock(&mutex);
    else
      rt_sem_v(&sema);

    rt_task_wait_period(NULL);
  }

}

void busManagement(void *cookie) {

  while(1) {

    if (WITH_MUTEX)
      rt_mutex_lock(&mutex, TM_INFINITE);
    else
      rt_sem_p(&sema, TM_INFINITE);

    rt_timer_spin(5*MS);

    if (WITH_MUTEX)
      rt_mutex_unlock(&mutex);
    else
      rt_sem_v(&sema);

    rt_task_wait_period(NULL);
  }
}

void comHandling(void *cookie) {

  while (1) {

    rt_timer_spin(10*MS);

    rt_task_wait_period(NULL);
  }

}

void alarmHandler(RT_ALARM *alarmDesc, void *cookie) {
  printk("#ALERT:\n");
}

void __exit cleanup_module (void) {

  printk("#cleanup\n");

  rt_task_delete(&meteoDataAcquisitionTask);
  rt_task_delete(&busManagementTask);
  rt_task_delete(&comHandlingTask);

  //rt_alarm_delete(&alarmBus);

  rt_mutex_delete(&mutex);
  rt_sem_delete(&sema);


  printk("Bye bye!\n");
}

int __init init_module (void) {

  printk("#starting...\n");

  err = rt_timer_set_mode(MS);
  if (err != 0) {
    printk("Error timer: %d\n", err);
    return -1;
  }

  err = rt_sem_create(&sema, "SEMAPHORE_BUS", 1, S_PRIO);
  if (err != 0) {
    printk("semaphore creation failed: %d\n", err);
    return -1;
  } 

  err = rt_mutex_create(&mutex, "MUTEX_BUS");
  if (err != 0) {
    printk("mutex creation failed: %d\n", err);
    return -1;
  }

  err = rt_task_create(&busManagementTask, "busManagement", STACK_SIZE, 10, 0);
  if (err != 0) {
    printk("task creation failed: %d\n", err);
    return -1;
  }

  err = rt_task_create(&meteoDataAcquisitionTask, "meteoDataAcquisition", STACK_SIZE, 1, 0);
  if (err != 0) {
    printk("task creation failed: %d\n", err);
    return -1;
  }

  err = rt_task_create(&comHandlingTask, "comHandling", STACK_SIZE, 5 , 0);
  if (err != 0) {
    printk("task creation failed: %d\n", err);
    return -1;
  }

  rt_task_set_periodic(&busManagementTask, TM_NOW, 20);
  rt_task_set_periodic(&comHandlingTask, TM_NOW, 20);
  rt_task_set_periodic(&meteoDataAcquisitionTask, 18, 1000); /* Delay this task in order to force priority inversion */

  rt_task_start(&comHandlingTask, comHandling, NULL);
  rt_task_start(&busManagementTask, busManagement, NULL);
  rt_task_start(&meteoDataAcquisitionTask, meteoDataAcquisition, NULL);

  return 0;
}

MODULE_LICENSE("GPL");

Re: [Xenomai-help] Strange behaviour w/mutex&semaphore

[Jan Kiszka]

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

ROSSIER Daniel wrote:
> Hi all,
> 
> I've a strange behaviour with the attached piece of code.
> It's really simple: there are 3 tasks and we're spinning within the task in order
> to simulate task load.
> 
> It's a pure academic exercice, so don't try to think about the usefulness of this code ;-)
> 
> 
> Actually, after insmod'ing the code into the kernel, the system freezes and
> the "meteoDataAcquisition" task is suspended runaway by the internal xenomai watchdog.
> 
> Why?
> 
> Anything wrong in this code?

Check the values you assign to rt_task_set_periodic. Kind of... fast?

> 
> Thanks for any advice.
> 
> Daniel
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

RE: [Xenomai-help] Strange behaviour w/mutex&semaphore

[ROSSIER Daniel]

> -----Message d'origine-----
> De : jan.kiszka@domain.hid [mailto:jan.kiszka@domain.hid]
> Envoyé : jeudi, 20. juillet 2006 13:03
> À : ROSSIER Daniel
> Cc : xenomai@xenomai.org
> Objet : Re: [Xenomai-help] Strange behaviour w/mutex&semaphore
> 
> ROSSIER Daniel wrote:
> > Hi all,
> >
> > I've a strange behaviour with the attached piece of code.
> > It's really simple: there are 3 tasks and we're spinning within the task
> in order
> > to simulate task load.
> >
> > It's a pure academic exercice, so don't try to think about the
> usefulness of this code ;-)
> >
> >
> > Actually, after insmod'ing the code into the kernel, the system freezes
> and
> > the "meteoDataAcquisition" task is suspended runaway by the internal
> xenomai watchdog.
> >
> > Why?
> >
> > Anything wrong in this code?
> 
> Check the values you assign to rt_task_set_periodic. Kind of... fast?

No, with at these frequencies, there is no problem (the jiffy is at 1ms). Actually, putting TM_NOW in the rt_task_set_periodic() instead of 18 as it is, we noticed that it works.
Removing the mutex & semaphore stuff, with the delay in set_periodic(), does not change the behaviour.
We came up with this issue after another one, actually, with a more sophisticated code showing a priority inversion. We reduce the code, and then find this issue. I do not know it both issues are related, but I'd like
to solve this one first.

> 
> >
> > Thanks for any advice.
> >
> > Daniel
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Xenomai-help mailing list
> > Xenomai-help@domain.hid
> > https://mail.gna.org/listinfo/xenomai-help
> 

RE: [Xenomai-help] Strange behaviour w/mutex&semaphore

[Gilles Chanteperdrix]

ROSSIER Daniel wrote:
 > 
 > 
 > > -----Message d'origine-----
 > > De : jan.kiszka@domain.hid [mailto:jan.kiszka@domain.hid]
 > > Envoyé : jeudi, 20. juillet 2006 13:03
 > > À : ROSSIER Daniel
 > > Cc : xenomai@xenomai.org
 > > Objet : Re: [Xenomai-help] Strange behaviour w/mutex&semaphore
 > > 
 > > ROSSIER Daniel wrote:
 > > > Hi all,
 > > >
 > > > I've a strange behaviour with the attached piece of code.
 > > > It's really simple: there are 3 tasks and we're spinning within the task
 > > in order
 > > > to simulate task load.
 > > >
 > > > It's a pure academic exercice, so don't try to think about the
 > > usefulness of this code ;-)
 > > >
 > > >
 > > > Actually, after insmod'ing the code into the kernel, the system freezes
 > > and
 > > > the "meteoDataAcquisition" task is suspended runaway by the internal
 > > xenomai watchdog.
 > > >
 > > > Why?
 > > >
 > > > Anything wrong in this code?
 > > 
 > > Check the values you assign to rt_task_set_periodic. Kind of... fast?
 > 
 > No, with at these frequencies, there is no problem (the jiffy is at
 > 1ms).

There are two tasks with a period of 20 ms that are spinning 10 ms
each. Does not this put a 100% load on the RT system ? If yes, then
Linux has no time left to run. That is what the watchdog is here to
avoid. You should try reducing the spinning time in order to let some
time for Linux to run.

-- 


					    Gilles Chanteperdrix.

RE: [Xenomai-help] Strange behaviour w/mutex&semaphore

[ROSSIER Daniel]

> -----Message d'origine-----
> De : Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
> Envoyé : jeudi, 20. juillet 2006 13:50
> À : ROSSIER Daniel
> Cc : jan.kiszka@domain.hid; xenomai@xenomai.org
> Objet : RE: [Xenomai-help] Strange behaviour w/mutex&semaphore
> 
> ROSSIER Daniel wrote:
>  >
>  >
>  > > -----Message d'origine-----
>  > > De : jan.kiszka@domain.hid [mailto:jan.kiszka@domain.hid]
>  > > Envoyé : jeudi, 20. juillet 2006 13:03
>  > > À : ROSSIER Daniel
>  > > Cc : xenomai@xenomai.org
>  > > Objet : Re: [Xenomai-help] Strange behaviour w/mutex&semaphore
>  > >
>  > > ROSSIER Daniel wrote:
>  > > > Hi all,
>  > > >
>  > > > I've a strange behaviour with the attached piece of code.
>  > > > It's really simple: there are 3 tasks and we're spinning within the
> task
>  > > in order
>  > > > to simulate task load.
>  > > >
>  > > > It's a pure academic exercice, so don't try to think about the
>  > > usefulness of this code ;-)
>  > > >
>  > > >
>  > > > Actually, after insmod'ing the code into the kernel, the system
> freezes
>  > > and
>  > > > the "meteoDataAcquisition" task is suspended runaway by the
> internal
>  > > xenomai watchdog.
>  > > >
>  > > > Why?
>  > > >
>  > > > Anything wrong in this code?
>  > >
>  > > Check the values you assign to rt_task_set_periodic. Kind of... fast?
>  >
>  > No, with at these frequencies, there is no problem (the jiffy is at
>  > 1ms).
> 
> There are two tasks with a period of 20 ms that are spinning 10 ms
> each. Does not this put a 100% load on the RT system ? If yes, then
> Linux has no time left to run. That is what the watchdog is here to
> avoid. You should try reducing the spinning time in order to let some
> time for Linux to run.

No, there are: 
- a task "MeteoDataAcquisition", with a spin of 10ms, and a period of 1s (1000ms).
- a task "BusManagement", with a spin of 5ms, and a period of 20ms
- a task "ComHandling", with a spin of 10ms, and a period of 20ms.

So actually, the CPU load is 10/1000 + 5/20 + 10/20 = 0.76; and this gives Linux chance to run. (But again Gilles, it works with the following statement:  rt_task_set_periodic(&meteoDataAcquisitionTask, TM_NOW, 1000);

I don't understand why it doesn't work with a delay of 18ms on the first release point of this task.

> --
> 
> 

Daniel

RE: [Xenomai-help] Strange behaviour w/mutex&semaphore

[Philippe Gerum]

On Thu, 2006-07-20 at 13:17 +0200, ROSSIER Daniel wrote:
> 
> > -----Message d'origine-----
> > De : jan.kiszka@domain.hid [mailto:jan.kiszka@domain.hid]
> > Envoyé : jeudi, 20. juillet 2006 13:03
> > À : ROSSIER Daniel
> > Cc : xenomai@xenomai.org
> > Objet : Re: [Xenomai-help] Strange behaviour w/mutex&semaphore
> > 
> > ROSSIER Daniel wrote:
> > > Hi all,
> > >
> > > I've a strange behaviour with the attached piece of code.
> > > It's really simple: there are 3 tasks and we're spinning within the task
> > in order
> > > to simulate task load.
> > >
> > > It's a pure academic exercice, so don't try to think about the
> > usefulness of this code ;-)
> > >
> > >
> > > Actually, after insmod'ing the code into the kernel, the system freezes
> > and
> > > the "meteoDataAcquisition" task is suspended runaway by the internal
> > xenomai watchdog.
> > >
> > > Why?
> > >
> > > Anything wrong in this code?
> > 
> > Check the values you assign to rt_task_set_periodic. Kind of... fast?
> 
> No, with at these frequencies, there is no problem (the jiffy is at 1ms). Actually, putting TM_NOW in the rt_task_set_periodic() instead of 18 as it is, we noticed that it works.
> Removing the mutex & semaphore stuff, with the delay in set_periodic(), does not change the behaviour.
> We came up with this issue after another one, actually, with a more sophisticated code showing a priority inversion. We reduce the code, and then find this issue. I do not know it both issues are related, but I'd like
> to solve this one first.
> 

-  rt_task_set_periodic(&meteoDataAcquisitionTask, 18, 1000);
+  rt_task_set_periodic(&meteoDataAcquisitionTask, rt_timer_read() + 18,
1000);

The current call should return with -ETIMEDOUT, in which case, the
associated acquisition thread would enter a runaway loop, with
rt_task_wait_period() systematically bailing out upon the same error,
which in turn makes the task sucking all the available CPU. Then came
the relentless watchdog...

> > 
> > >
> > > Thanks for any advice.
> > >
> > > Daniel
> > >
> > >
> > >
> > > ------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > Xenomai-help mailing list
> > > Xenomai-help@domain.hid
> > > https://mail.gna.org/listinfo/xenomai-help
> > 
> 
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.

RE: [Xenomai-help] Strange behaviour w/mutex&semaphore

[ROSSIER Daniel]

> -----Message d'origine-----
> De : Philippe Gerum [mailto:rpm@xenomai.org]
> Envoyé : jeudi, 20. juillet 2006 14:04
> À : ROSSIER Daniel
> Cc : jan.kiszka@domain.hid; xenomai@xenomai.org
> Objet : RE: [Xenomai-help] Strange behaviour w/mutex&semaphore
> 
> On Thu, 2006-07-20 at 13:17 +0200, ROSSIER Daniel wrote:
> >
> > > -----Message d'origine-----
> > > De : jan.kiszka@domain.hid [mailto:jan.kiszka@domain.hid]
> > > Envoyé : jeudi, 20. juillet 2006 13:03
> > > À : ROSSIER Daniel
> > > Cc : xenomai@xenomai.org
> > > Objet : Re: [Xenomai-help] Strange behaviour w/mutex&semaphore
> > >
> > > ROSSIER Daniel wrote:
> > > > Hi all,
> > > >
> > > > I've a strange behaviour with the attached piece of code.
> > > > It's really simple: there are 3 tasks and we're spinning within the
> task
> > > in order
> > > > to simulate task load.
> > > >
> > > > It's a pure academic exercice, so don't try to think about the
> > > usefulness of this code ;-)
> > > >
> > > >
> > > > Actually, after insmod'ing the code into the kernel, the system
> freezes
> > > and
> > > > the "meteoDataAcquisition" task is suspended runaway by the internal
> > > xenomai watchdog.
> > > >
> > > > Why?
> > > >
> > > > Anything wrong in this code?
> > >
> > > Check the values you assign to rt_task_set_periodic. Kind of... fast?
> >
> > No, with at these frequencies, there is no problem (the jiffy is at
> 1ms). Actually, putting TM_NOW in the rt_task_set_periodic() instead of 18
> as it is, we noticed that it works.
> > Removing the mutex & semaphore stuff, with the delay in set_periodic(),
> does not change the behaviour.
> > We came up with this issue after another one, actually, with a more
> sophisticated code showing a priority inversion. We reduce the code, and
> then find this issue. I do not know it both issues are related, but I'd
> like
> > to solve this one first.
> >
> 
> -  rt_task_set_periodic(&meteoDataAcquisitionTask, 18, 1000);
> +  rt_task_set_periodic(&meteoDataAcquisitionTask, rt_timer_read() + 18,
> 1000);
> 
> The current call should return with -ETIMEDOUT, in which case, the
> associated acquisition thread would enter a runaway loop, with
> rt_task_wait_period() systematically bailing out upon the same error,
> which in turn makes the task sucking all the available CPU. Then came
> the relentless watchdog...

Of course! It's absolute time as well explained in the API. Thanks a lot Philippe; I need some Holidays ;-) So, I will now post the real issue we have with the priority inversion, probably another easy fix to find out ;)

> 
> > >
> > > >
> > > > Thanks for any advice.
> > > >
> > > > Daniel
> > > >
> > > >
> > > >
> > > > --------------------------------------------------------------------
> ----
> > > >
> > > > _______________________________________________
> > > > Xenomai-help mailing list
> > > > Xenomai-help@domain.hid
> > > > https://mail.gna.org/listinfo/xenomai-help
> > >
> >
> >
> >
> > _______________________________________________
> > Xenomai-help mailing list
> > Xenomai-help@domain.hid
> > https://mail.gna.org/listinfo/xenomai-help
> --
> Philippe.
> 

Daniel