[Xenomai] Question about scheduling and signals

[Xenomai] Question about scheduling and signals

[Matthias Schneider]

Hi all,

currently I am trying to make the following FreeRTOS test case run on 
forge/mercury on linux preempt_rt:


//Task 1, prio 1 / SCHED_FIFO
for(;;) {
  (*pulCounter)++;
  if( *pulCounter >= priMAX_COUNT )
     vTaskSuspend(NULL); // -> wait for signal SIGRESM
}

//Task 2, prio 0 / SCHED_OTHER
vTaskSuspendAll(); //-> sched_lock
vTaskResume(xLimitedIncrementHandle); //-> sends SIGRESM
xTaskResumeAll(); //-> sched_unlock, seems not to unlock the waiting task
                  // right away (because signal is not yet delivered?)
if (ulCounter != priMAX_COUNT)
  raise(SIGABRT);

Consider task 1 in vTaskSuspend. Task 2 will take the "scheduler lock", i.e. 
raises its priority. vTaskResume will then signal task 1 to resume via 
sending SIGRESM. Once xTaskResumeAll lowers task 2's priority to 0, 
I would expect task 1 to be executed right away. However it seems that
this is not the case - SIGABRT is raised instead.

What I do not fully understand is the delivery of the signal to task 1, which 
should unblock it, allowing it to run once task calls xTaskResumeAll().
When the signal is sent, task 2 is still the highest priority task in the 
process and will thus simply go on with its execution. Now, the signal seems
to be queued for task 1 somehow, but it is unclear to me when it is 
actually delivered (apparently task 1 is not scheduled right away once task 2 
calls xTaskResumeAll). Could anyone point me into the right direction where
to find the solution to this behavior (i.e. source-code wise)? 

Actually I am starting to have doubts about this this test case actually being 
is worth the headaches since we already agreed on supporting 
vTaskSuspendAll/xTaskResumeAll only partially on xenomai-forge, but it would 
still be interesting to understand the mentioned behavior...

Thanks in advance for your help.

Matthias

Re: [Xenomai] Question about scheduling and signals

[Gilles Chanteperdrix]

On 05/24/2014 09:05 PM, Matthias Schneider wrote:
> Hi all,
> 
> currently I am trying to make the following FreeRTOS test case run on 
> forge/mercury on linux preempt_rt:
> 
> 
> //Task 1, prio 1 / SCHED_FIFO
> for(;;) {
>   (*pulCounter)++;
>   if( *pulCounter >= priMAX_COUNT )
>      vTaskSuspend(NULL); // -> wait for signal SIGRESM
> }
> 
> //Task 2, prio 0 / SCHED_OTHER
> vTaskSuspendAll(); //-> sched_lock
> vTaskResume(xLimitedIncrementHandle); //-> sends SIGRESM
> xTaskResumeAll(); //-> sched_unlock, seems not to unlock the waiting task
>                   // right away (because signal is not yet delivered?)

At this point, task 1 wakes up, increments ulCounter again, then suspend
again, so now ulCounter == priMAX_COUNT + 1

> if (ulCounter != priMAX_COUNT)
>   raise(SIGABRT);

So this test fails, and you get a SIGABORT

I do not see how this test could do anything else than throwing a
SIGABORT. Also note that on multi-processor systems, if task 0 and task
1 are not running on the same CPU, there is a race between task 1
incrementing the counter and task 2 reading its value to compare it to
priMAX_COUNT.



-- 
                                                                Gilles.

Re: [Xenomai] Question about scheduling and signals

[Matthias Schneider]

----- Original Message -----

> From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
> To: Matthias Schneider <ma30002000@yahoo.de>; "xenomai@xenomai.org" <xenomai@xenomai.org>
> Cc: 
> Sent: Saturday, May 24, 2014 9:37 PM
> Subject: Re: [Xenomai] Question about scheduling and signals
> 
> On 05/24/2014 09:05 PM, Matthias Schneider wrote:
>>  Hi all,
>> 
>>  currently I am trying to make the following FreeRTOS test case run on 
>>  forge/mercury on linux preempt_rt:
>> 
>> 
>>  //Task 1, prio 1 / SCHED_FIFO
>>  for(;;) {
>>    (*pulCounter)++;
>>    if( *pulCounter >= priMAX_COUNT )
>>       vTaskSuspend(NULL); // -> wait for signal SIGRESM
>>  }
>> 
>>  //Task 2, prio 0 / SCHED_OTHER
>>  vTaskSuspendAll(); //-> sched_lock
>>  vTaskResume(xLimitedIncrementHandle); //-> sends SIGRESM
>>  xTaskResumeAll(); //-> sched_unlock, seems not to unlock the waiting 
> task
>>                    // right away (because signal is not yet delivered?)
> 
> At this point, task 1 wakes up, increments ulCounter again, then suspend
> again, so now ulCounter == priMAX_COUNT + 1


Why priMAX_COUNT + 1? Shouldnt vTaskSuspend be triggered when 
*pulCounter == priMAX_COUNT (which is actually is once task 1 gets
scheduled while task 2 is raising abort - at least my debugger tells me 
it is).

>>  if (ulCounter != priMAX_COUNT)
>>    raise(SIGABRT);
> 
> So this test fails, and you get a SIGABORT
> 
> I do not see how this test could do anything else than throwing a
> SIGABORT. Also note that on multi-processor systems, if task 0 and task
> 1 are not running on the same CPU, there is a race between task 1
> incrementing the counter and task 2 reading its value to compare it to
> priMAX_COUNT.


Correct, however I forgot to mention that I set CPU affinity to make the 
process use a single CPU (which has basically worked for all scenarios I 
had previously investigated).

Re: [Xenomai] Question about scheduling and signals

[Gilles Chanteperdrix]

On 05/24/2014 09:55 PM, Matthias Schneider wrote:
> ----- Original Message -----
> 
>> From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
>> To: Matthias Schneider <ma30002000@yahoo.de>; "xenomai@xenomai.org" <xenomai@xenomai.org>
>> Cc: 
>> Sent: Saturday, May 24, 2014 9:37 PM
>> Subject: Re: [Xenomai] Question about scheduling and signals
>>
>> On 05/24/2014 09:05 PM, Matthias Schneider wrote:
>>>  Hi all,
>>>
>>>  currently I am trying to make the following FreeRTOS test case run on 
>>>  forge/mercury on linux preempt_rt:
>>>
>>>
>>>  //Task 1, prio 1 / SCHED_FIFO
>>>  for(;;) {
>>>    (*pulCounter)++;
>>>    if( *pulCounter >= priMAX_COUNT )
>>>       vTaskSuspend(NULL); // -> wait for signal SIGRESM
>>>  }
>>>
>>>  //Task 2, prio 0 / SCHED_OTHER
>>>  vTaskSuspendAll(); //-> sched_lock
>>>  vTaskResume(xLimitedIncrementHandle); //-> sends SIGRESM
>>>  xTaskResumeAll(); //-> sched_unlock, seems not to unlock the waiting 
>> task
>>>                    // right away (because signal is not yet delivered?)
>>
>> At this point, task 1 wakes up, increments ulCounter again, then suspend
>> again, so now ulCounter == priMAX_COUNT + 1
> 
> 
> Why priMAX_COUNT + 1? Shouldnt vTaskSuspend be triggered when 
> *pulCounter == priMAX_COUNT (which is actually is once task 1 gets
> scheduled while task 2 is raising abort - at least my debugger tells me 
> it is).

The task1 first suspends when pulCounter == priMAX_COUNT, right?
Then you wake it up, so, since there is a for loop, it will do

>>>    (*pulCounter)++;
>>>    if( *pulCounter >= priMAX_COUNT )
>>>       vTaskSuspend(NULL); // -> wait for signal SIGRESM

So, now task 1 is suspended again, and *pulCounter == priMAX_COUNT + 1

-- 
                                                                Gilles.

Re: [Xenomai] Question about scheduling and signals

[Matthias Schneider]

----- Original Message -----

> From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
> On 05/24/2014 09:55 PM, Matthias Schneider wrote:
>>  ----- Original Message -----
>>>  From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
[...]
>> 
>>  Why priMAX_COUNT + 1? Shouldnt vTaskSuspend be triggered when 
>>  *pulCounter == priMAX_COUNT (which is actually is once task 1 gets
>>  scheduled while task 2 is raising abort - at least my debugger tells me 
>>  it is).
> 
> The task1 first suspends when pulCounter == priMAX_COUNT, right?
> Then you wake it up, so, since there is a for loop, it will do
> 
>>>>     (*pulCounter)++;
>>>>     if( *pulCounter >= priMAX_COUNT )
>>>>        vTaskSuspend(NULL); // -> wait for signal SIGRESM
> 
> So, now task 1 is suspended again, and *pulCounter == priMAX_COUNT + 1



You are right, I forgot to include an essential piece of code in my 
first snippet(sorry about that):

//Task 1, prio 1 / SCHED_FIFO

vTaskSuspend(NULL); // forgot this in my first snippet
for(;;) {

  (*pulCounter)++;
  if( *pulCounter >= priMAX_COUNT )
     vTaskSuspend(NULL);
}

//Task 2, prio 0 / SCHED_OTHER
vTaskSuspendAll();
vTaskResume(xLimitedIncrementHandle);
xTaskResumeAll(); 
                 
if (ulCounter != priMAX_COUNT)
  raise(SIGABRT);


Now task will block in the first suspend. Task 2 will do its thing,
and when task 2's priority gets lowered, I would expect task 1 being
scheduled right away, increasing the counter up to priMAX_COUNT, before
task 2 is scheduled again when task 1 enters the second vTaskSuspend.
However, ulCounter seems to be 0 when SIGABRT is raised.

Matthias

Re: [Xenomai] Question about scheduling and signals

[Gilles Chanteperdrix]

On 05/24/2014 10:50 PM, Matthias Schneider wrote:
> ----- Original Message -----
> 
>> From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
>> On 05/24/2014 09:55 PM, Matthias Schneider wrote:
>>>  ----- Original Message -----
>>>>  From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
> [...]
>>>
>>>  Why priMAX_COUNT + 1? Shouldnt vTaskSuspend be triggered when 
>>>  *pulCounter == priMAX_COUNT (which is actually is once task 1 gets
>>>  scheduled while task 2 is raising abort - at least my debugger tells me 
>>>  it is).
>>
>> The task1 first suspends when pulCounter == priMAX_COUNT, right?
>> Then you wake it up, so, since there is a for loop, it will do
>>
>>>>>     (*pulCounter)++;
>>>>>     if( *pulCounter >= priMAX_COUNT )
>>>>>        vTaskSuspend(NULL); // -> wait for signal SIGRESM
>>
>> So, now task 1 is suspended again, and *pulCounter == priMAX_COUNT + 1
> 
> 
> 
> You are right, I forgot to include an essential piece of code in my 
> first snippet(sorry about that):
> 
> //Task 1, prio 1 / SCHED_FIFO
> 
> vTaskSuspend(NULL); // forgot this in my first snippet
> for(;;) {
> 
>   (*pulCounter)++;
>   if( *pulCounter >= priMAX_COUNT )
>      vTaskSuspend(NULL);
> }
> 
> //Task 2, prio 0 / SCHED_OTHER
> vTaskSuspendAll();
> vTaskResume(xLimitedIncrementHandle);
> xTaskResumeAll(); 
>                  
> if (ulCounter != priMAX_COUNT)
>   raise(SIGABRT);
> 
> 
> Now task will block in the first suspend. Task 2 will do its thing,
> and when task 2's priority gets lowered, I would expect task 1 being
> scheduled right away, increasing the counter up to priMAX_COUNT, before
> task 2 is scheduled again when task 1 enters the second vTaskSuspend.
> However, ulCounter seems to be 0 when SIGABRT is raised.

Are you running an uniprocessor, or multi-processor system?

-- 
                                                                Gilles.

Re: [Xenomai] Question about scheduling and signals

[Matthias Schneider]

----- Original Message -----
> From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
> To: Matthias Schneider <ma30002000@yahoo.de>; "xenomai@xenomai.org" <xenomai@xenomai.org>
> Cc: 
> Sent: Saturday, May 24, 2014 11:17 PM
> Subject: Re: [Xenomai] Question about scheduling and signals
> 
> On 05/24/2014 10:50 PM, Matthias Schneider wrote:
>>  ----- Original Message -----
>> 
>>>  From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
>>>  On 05/24/2014 09:55 PM, Matthias Schneider wrote:
>>>>   ----- Original Message -----
>>>>>   From: Gilles Chanteperdrix 
> <gilles.chanteperdrix@xenomai.org>
>>  [...]
>>>> 
>>>>   Why priMAX_COUNT + 1? Shouldnt vTaskSuspend be triggered when 
>>>>   *pulCounter == priMAX_COUNT (which is actually is once task 1 gets
>>>>   scheduled while task 2 is raising abort - at least my debugger 
> tells me 
>>>>   it is).
>>> 
>>>  The task1 first suspends when pulCounter == priMAX_COUNT, right?
>>>  Then you wake it up, so, since there is a for loop, it will do
>>> 
>>>>>>      (*pulCounter)++;
>>>>>>      if( *pulCounter >= priMAX_COUNT )
>>>>>>         vTaskSuspend(NULL); // -> wait for signal SIGRESM
>>> 
>>>  So, now task 1 is suspended again, and *pulCounter == priMAX_COUNT + 1
>> 
>> 
>> 
>>  You are right, I forgot to include an essential piece of code in my 
>>  first snippet(sorry about that):
>> 
>>  //Task 1, prio 1 / SCHED_FIFO
>> 
>>  vTaskSuspend(NULL); // forgot this in my first snippet
>>  for(;;) {
>> 
>>    (*pulCounter)++;
>>    if( *pulCounter >= priMAX_COUNT )
>>       vTaskSuspend(NULL);
>>  }
>> 
>>  //Task 2, prio 0 / SCHED_OTHER
>>  vTaskSuspendAll();
>>  vTaskResume(xLimitedIncrementHandle);
>>  xTaskResumeAll(); 
>>                   
>>  if (ulCounter != priMAX_COUNT)
>>    raise(SIGABRT);
>> 
>> 
>>  Now task will block in the first suspend. Task 2 will do its thing,
>>  and when task 2's priority gets lowered, I would expect task 1 being
>>  scheduled right away, increasing the counter up to priMAX_COUNT, before
>>  task 2 is scheduled again when task 1 enters the second vTaskSuspend.
>>  However, ulCounter seems to be 0 when SIGABRT is raised.
> 
> Are you running an uniprocessor, or multi-processor system?
> 


It was an mp system, but with processor affinity set and pegged to 
a single core (which had so far produced the expected results in 
other tests).