From: Jan Kiszka <jan.kiszka@domain.hid>
To: Anders Blomdell <anders.blomdell@domain.hid>
Cc: Xenomai-help@domain.hid
Subject: Re: [Xenomai-help] Make error
Date: Thu, 15 Feb 2007 11:17:32 +0100 [thread overview]
Message-ID: <45D4333C.7090907@domain.hid> (raw)
In-Reply-To: <45D431CF.5090201@domain.hid>
[-- Attachment #1: Type: text/plain, Size: 4063 bytes --]
Anders Blomdell wrote:
> Preetam Joshi wrote:
>> ok,
>>
>> here is the code.
>> The code essentially cerates two tasks low and high priority task.
>> The low priority task has priority as 3 and high as 98
>>
>> When i execute this initally everything goes smoothly as low priority
>> task
>> starts running with priority thread 3 , it sleeps so then the high
>> priority
>> thread runs with priority 98. But before the high priority thread
>> finishes
>> the for loop for 7 times the low priority thread prempts it and starts
>> running with priority = 98.
> Nope, you just don't read the state (using a global is also a bad idea).
>
...and the code contains lots of "printf" which switches away from
Xenomai into Linux mode with the potential to screw up the schedule as
well. Don't use printf in RT code unless you can live with potential
priority inversion during its execution.
>>
>> This is what has baffled me?
>>
>> #include <stdio.h>
>> #include <unistd.h>
>> #include <sys/mman.h>
>> #include <native/task.h>
>> #include <native/timer.h>
>>
>> RT_TASK task1;
>> RT_TASK task2;
>> RT_TASK_INFO info;
>>
>> void low_task(void *arg)
>> {
> RT_TASK_INFO info;
>> rt_task_inquire(&task1, &info);
>> printf("Priority of low task %d\n", info.cprio);
>>
>> rt_task_sleep(3000000000);
>>
>> while(1)
>> {
> rt_task_inquire(&task1, &info);
>> printf("Priority of Low task %d\n",info.cprio);
>> }
>>
>> }
>>
>> void high_task(void *arg)
>> {
>> unsigned int i;
>> rt_task_inquire(&task2, &info);
>> printf("Priority of high task before sleep %d\n", info.cprio);
>> for(i=0;i<7;i++)
>> {
>>
>> printf("Priority of High Priotity task1 %d\n",info.cprio);
>> rt_task_sleep(1000000000);
>> }
>>
>> printf("High priority thread goin to sleep %d\n",info.cprio);
>> rt_task_sleep(3000000000);
>>
>> for(i=0;i<100;i++)
>> {
>> printf("Priority of High task2 %d\n",info.cprio);
>> }
>>
>> int main(int argc, char* argv[])
>> {
>> mlockall(MCL_CURRENT|MCL_FUTURE);
>>
>> rt_task_create(&task1, "Low Priority Task", 0, 3, 0);
>> rt_task_create(&task2, "High Priority Task", 0, 98, 0);
>>
>> rt_task_start(&task1, &low_task, NULL);
>> rt_task_start(&task2, &high_task, NULL);
>>
>> pause();
>>
>> rt_task_join(&task1);
>> rt_task_join(&task2);
>>
>> }
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 2/15/07, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>>>
>>> Preetam Joshi wrote:
>>> > Hi,
>>> >
>>> > Do u mean to say that if i have created my tasks using native xenomai
>>> API's
>>> > like rt_task_create , then inside those tasks i will have to use posix
>>> skin
>>> > calls like pthread_setschedpolicy, etc...?
>>> >
>>> > Is that so.
>>>
>>> Nope. If you picked the native skin API, all scheduler setup for a RT
>>> task should be done through that interface.
>>>
>>> >
>>> > Cant i just have context switch between the tasks themselves say low
>>> > priority and a high priority task created by rt_task_create.
>>> >
>>> > Reason being i have created two tasks using the rt_task_create API and
>>> my
>>> > high priority task is runnning and my low priority task has slept,
>>> so as
>>> > soon as my low priority task has expired its sleep time and gets ready
>>> to
>>> > run,
>>> >
>>> > The low priority task preempts my high priority task and even its
>>> priority
>>> > gets raised to that of the high priority task and starts executing.
>>> The
>>> > higgh priority task gets suspended altogether amidst its running.
>>> Simply
>>> > baffled by the behavior?
>>>
>>> If you have found a weird behaviour of Xenomai, please post some
>>> as-small-as-possible demo code that exposes the issue. We will have a
>>> look at it.
>>>
> Regards
>
> Anders
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
next prev parent reply other threads:[~2007-02-15 10:17 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-12 5:24 [Xenomai-help] Make error Preetam Joshi
2007-02-12 7:20 ` Markus Franke
2007-02-12 8:47 ` Jan Kiszka
[not found] ` <e45fe62b0702120448i7b23bd24o4fa88a05237a69a@domain.hid>
2007-02-12 13:06 ` Jan Kiszka
2007-02-13 7:19 ` Preetam Joshi
2007-02-13 8:08 ` Jan Kiszka
[not found] ` <e45fe62b0702130021i5ec6c345m699a9abcc2e665c0@domain.hid>
2007-02-13 10:28 ` Jan Kiszka
2007-02-14 5:57 ` Preetam Joshi
2007-02-14 8:53 ` Jan Kiszka
2007-02-15 7:19 ` Preetam Joshi
2007-02-15 9:03 ` Jan Kiszka
2007-02-15 9:58 ` Preetam Joshi
2007-02-15 10:11 ` Anders Blomdell
2007-02-15 10:16 ` Preetam Joshi
2007-02-15 10:30 ` Gilles Chanteperdrix
2007-02-15 12:00 ` Philippe Gerum
2007-02-21 8:12 ` Preetam Joshi
2007-02-21 8:18 ` Preetam Joshi
2007-02-15 10:17 ` Jan Kiszka [this message]
2007-02-13 9:00 ` Gilles Chanteperdrix
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45D4333C.7090907@domain.hid \
--to=jan.kiszka@domain.hid \
--cc=Xenomai-help@domain.hid \
--cc=anders.blomdell@domain.hid \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.