>
> > But if the priority of the "world" component is higher than the
> > priority of the "Hello" component, why is the "World" component not
> > woken up when the "Hello" component emits an event?
> >
> > In this case it shouldn't be a problem that the event queue can only
> > contain one event per event type. The "World" component should be
> > rescheduled when an event is emitted. But if I run this program under
> > xenomai, I only see the first event, the second event is still lost.
>
> The only reason can be that the rescheduling did not happen when we
> raised the semaphore on which the high priority thread was blocking.
> Dit you check in /proc/xenomai/sched that the effective priorities are
> what you expect ? Do you see mode switches while running your test
> program ?
>
I suspect you are still passing std::strings as arguments and RTT::Logger in
your callbacks? They you are not running real-time any more. So I guess the
priority you defined doesn't matter any more.
Try using int's and a buffered data port to a third component to do the
RTT::Logging. Then your priorities should be respected.
Butch.
Fwd: Event emitted multiple times is lost in event queue
On Thu, Oct 8, 2009 at 3:51 PM, Butch Slayer <butch [dot] slayers [..] ...> wrote:
>
>
>> >
>> > But if the priority of the "world" component is higher than the
>> > priority of the "Hello" component, why is the "World" component not
>> > woken up when the "Hello" component emits an event?
>> >
>> > In this case it shouldn't be a problem that the event queue can only
>> > contain one event per event type. The "World" component should be
>> > rescheduled when an event is emitted. But if I run this program under
>> > xenomai, I only see the first event, the second event is still lost.
>>
>> The only reason can be that the rescheduling did not happen when we
>> raised the semaphore on which the high priority thread was blocking.
>> Dit you check in /proc/xenomai/sched that the effective priorities are
>> what you expect ? Do you see mode switches while running your test
>> program ?
>
> I suspect you are still passing std::strings as arguments and RTT::Logger in
> your callbacks? They you are not running real-time any more. So I guess the
> priority you defined doesn't matter any more.
>
> Try using int's and a buffered data port to a third component to do the
> RTT::Logging. Then your priorities should be respected.
Ok it works now under xenomai but still not under gnulinux (run it as root).
Fwd: Event emitted multiple times is lost in event queue
On Thu, Oct 15, 2009 at 12:21 PM, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
> On Thu, Oct 15, 2009 at 12:00 PM, Peter Soetens
> <peter [..] ...> wrote:
>> On Wed, Oct 14, 2009 at 16:55, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
>>> On Mon, Oct 12, 2009 at 9:04 AM, Steven Kauffmann
>>> <steven [dot] kauffmann [..] ...> wrote:
>>>> On Thu, Oct 8, 2009 at 3:51 PM, Butch Slayer <butch [dot] slayers [..] ...> wrote:
>>>>>> > But if the priority of the "world" component is higher than the
>>>>>> > priority of the "Hello" component, why is the "World" component not
>>>>>> > woken up when the "Hello" component emits an event?
>>> [...]
>>>>> Try using int's and a buffered data port to a third component to do the
>>>>> RTT::Logging. Then your priorities should be respected.
>>>>
>>>> Ok it works now under xenomai but still not under gnulinux (run it as root).
>>>
>>> I did some small testing with the file in attachment (slightly
>>> modified from Stevens original file). IIANM, the strings can be
>>> "perfectly" used in gnulinux (i.e. they shouldn't modify the desired
>>> behaviour in this case). The linux FIFO scheduler should be
>>> preemptive (according to its docs), so the same thing should work
>>> under gnulinux too.
>>
>> That's strange. I vaguely remembered that it isn't preemptive.
>>
>>>
>>> However, also in my case, it does _not_. Now, interesting enough,
>>> when I put the eventSender in the ORO_SCHED_OTHER (SCHED_OTHER) and
>>> leave the receiver in ORO_SCHED_RT (SCHED_FIFO), I do observe the
>>> intended behaviour
>>
>> Which would prove my point ? If sender is FIFO, it won't give up the cpu.
>
> I got my info from "man sched_setscheduler"
>
> <quote>
> All scheduling is preemptive: if a process with a higher static
> priority becomes ready to run, the currently running process will be
> preempted and returned to the wait list for its static priority level.
> The scheduling policy only determines the ordering within the list of
> runnable processes with equal static priority.
> <quote>
Sighhh, seems like even the posix docs are not in sync with their
implementation. See attach (and feel free to correct any errors I
might have put in the code). To check, uncomment one of the
following and observe the behaviour.
pthread_attr_setschedpolicy(&attr1, SCHED_FIFO);
// pthread_attr_setschedpolicy(&attr1, SCHED_OTHER);
gcc -g SemaphoreSchedFIFO.c -lpthread -lrt
will do the trick.
Klaas
Fwd: Event emitted multiple times is lost in event queue
On Mon, Oct 26, 2009 at 05:24:54PM +0100, Klaas Gadeyne wrote:
> On Thu, Oct 15, 2009 at 12:21 PM, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
> > On Thu, Oct 15, 2009 at 12:00 PM, Peter Soetens
> > <peter [..] ...> wrote:
> >> On Wed, Oct 14, 2009 at 16:55, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
> >>> On Mon, Oct 12, 2009 at 9:04 AM, Steven Kauffmann
> >>> <steven [dot] kauffmann [..] ...> wrote:
> >>>> On Thu, Oct 8, 2009 at 3:51 PM, Butch Slayer <butch [dot] slayers [..] ...> wrote:
> >>>>>> > But if the priority of the "world" component is higher than the
> >>>>>> > priority of the "Hello" component, why is the "World" component not
> >>>>>> > woken up when the "Hello" component emits an event?
> >>> [...]
> >>>>> Try using int's and a buffered data port to a third component to do the
> >>>>> RTT::Logging. Then your priorities should be respected.
> >>>>
> >>>> Ok it works now under xenomai but still not under gnulinux (run it as root).
> >>>
> >>> I did some small testing with the file in attachment (slightly
> >>> modified from Stevens original file). IIANM, the strings can be
> >>> "perfectly" used in gnulinux (i.e. they shouldn't modify the desired
> >>> behaviour in this case). The linux FIFO scheduler should be
> >>> preemptive (according to its docs), so the same thing should work
> >>> under gnulinux too.
> >>
> >> That's strange. I vaguely remembered that it isn't preemptive.
> >>
> >>>
> >>> However, also in my case, it does _not_. Now, interesting enough,
> >>> when I put the eventSender in the ORO_SCHED_OTHER (SCHED_OTHER) and
> >>> leave the receiver in ORO_SCHED_RT (SCHED_FIFO), I do observe the
> >>> intended behaviour
> >>
> >> Which would prove my point ? If sender is FIFO, it won't give up the cpu.
> >
> > I got my info from "man sched_setscheduler"
> >
> > <quote>
> > All scheduling is preemptive: if a process with a higher static
> > priority becomes ready to run, the currently running process will be
> > preempted and returned to the wait list for its static priority level.
> > The scheduling policy only determines the ordering within the list of
> > runnable processes with equal static priority.
> > <quote>
>
> Sighhh, seems like even the posix docs are not in sync with their
> implementation. See attach (and feel free to correct any errors I
> might have put in the code). To check, uncomment one of the
> following and observe the behaviour.
Can you explain what you are trying to show with this example? In any
case you don't think much about return values, do you? :-) Are you
sure that you're threads are created with the right priority and are
not failing with EPERM?
> pthread_attr_setschedpolicy(&attr1, SCHED_FIFO);
> // pthread_attr_setschedpolicy(&attr1, SCHED_OTHER);
>
> gcc -g SemaphoreSchedFIFO.c -lpthread -lrt
> will do the trick.
>
> Klaas
> #include <semaphore.h>
> #include <pthread.h>
> #include <stdio.h>
>
> sem_t sem;
>
> void * thread1code(void * args)
> {
> while(1)
> {
> printf("Hello 1\n");
> sem_post(&sem);
> printf("Hello 2\n");
> sleep(2);
> }
> }
>
> void * thread2code(void * args)
> {
> while(1)
> {
> sem_wait(&sem);
> printf("Hello received\n");
> }
> }
>
>
> int main()
> {
> pthread_t thread1, thread2;
> pthread_attr_t attr1, attr2;
> struct sched_param sp1, sp2;
> sp1.sched_priority = 1;
> sp2.sched_priority= 99;
>
> pthread_attr_init(&attr1);
> pthread_attr_init(&attr2);
>
> pthread_attr_setschedpolicy(&attr1, SCHED_FIFO);
> // pthread_attr_setschedpolicy(&attr1, SCHED_OTHER);
> pthread_attr_setschedpolicy(&attr2, SCHED_FIFO);
>
> pthread_attr_setschedparam(&attr1, &sp1);
> pthread_attr_setschedparam(&attr2, &sp2);
>
> sem_init(&sem,0,0);
>
> pthread_create(&thread1, &attr1, thread1code, 0);
> pthread_create(&thread2, &attr2, thread2code, 0);
>
> sleep(5);
> }
Markus
Fwd: Event emitted multiple times is lost in event queue
>> >>> I did some small testing with the file in attachment (slightly
>> >>> modified from Stevens original file). IIANM, the strings can be
>> >>> "perfectly" used in gnulinux (i.e. they shouldn't modify the desired
>> >>> behaviour in this case). The linux FIFO scheduler should be
>> >>> preemptive (according to its docs), so the same thing should work
>> >>> under gnulinux too.
>> >>
>> >> That's strange. I vaguely remembered that it isn't preemptive.
>> >>
>> >>>
>> >>> However, also in my case, it does _not_. Now, interesting enough,
>> >>> when I put the eventSender in the ORO_SCHED_OTHER (SCHED_OTHER) and
>> >>> leave the receiver in ORO_SCHED_RT (SCHED_FIFO), I do observe the
>> >>> intended behaviour
>> >>
>> >> Which would prove my point ? If sender is FIFO, it won't give up the cpu.
>> >
>> > I got my info from "man sched_setscheduler"
>> >
>> > <quote>
>> > All scheduling is preemptive: if a process with a higher static
>> > priority becomes ready to run, the currently running process will be
>> > preempted and returned to the wait list for its static priority level.
>> > The scheduling policy only determines the ordering within the list of
>> > runnable processes with equal static priority.
>> > <quote>
>>
>> Sighhh, seems like even the posix docs are not in sync with their
>> implementation. See attach (and feel free to correct any errors I
>> might have put in the code). To check, uncomment one of the
>> following and observe the behaviour.
>
> Can you explain what you are trying to show with this example?
Well, most of it should be clear from the previous posts in this
thread. This example is meant to show that the behaviour we observe
using orocos can be reproduced without orocos too, and hence it seems
like the non-preemptive behaviour is not due to orocos but to the
linux scheduler.
> In any
> case you don't think much about return values, do you? :-) Are you
> sure that you're threads are created with the right priority and are
> not failing with EPERM?
I use as many return values as the orocos gnulinux fosi does ;-)
I run the programs as root, by the way...
Fwd: Event emitted multiple times is lost in event queue
>
> Well, most of it should be clear from the previous posts in this
> thread. This example is meant to show that the behaviour we observe
> using orocos can be reproduced without orocos too, and hence it seems
> like the non-preemptive behaviour is not due to orocos but to the
> linux scheduler.
>
> Euhm, I thought this was already clear. OROCOS doesn't do scheduling so any
scheduling abnormality is due to the underling OS.
Butch.
Fwd: Event emitted multiple times is lost in event queue
On Thu, Oct 29, 2009 at 8:33 AM, Butch Slayer <butch [dot] slayers [..] ...> wrote:
>> Well, most of it should be clear from the previous posts in this
>> thread. This example is meant to show that the behaviour we observe
>> using orocos can be reproduced without orocos too, and hence it seems
>> like the non-preemptive behaviour is not due to orocos but to the
>> linux scheduler.
>>
> Euhm, I thought this was already clear. OROCOS doesn't do scheduling so any
> scheduling abnormality is due to the underling OS.
Correct. Unless orocos did something during the event emitting
process that influenced the scheduling decision of the OS somehow.
I must have gotten suspicious along the years, I apologize ;-))
Klaas
Fwd: Event emitted multiple times is lost in event queue
On Thu, Oct 8, 2009 at 15:51, Butch Slayer <butch [dot] slayers [..] ...> wrote:
>
>
>> >
>> > But if the priority of the "world" component is higher than the
>> > priority of the "Hello" component, why is the "World" component not
>> > woken up when the "Hello" component emits an event?
>> >
>> > In this case it shouldn't be a problem that the event queue can only
>> > contain one event per event type. The "World" component should be
>> > rescheduled when an event is emitted. But if I run this program under
>> > xenomai, I only see the first event, the second event is still lost.
>>
>> The only reason can be that the rescheduling did not happen when we
>> raised the semaphore on which the high priority thread was blocking.
>> Dit you check in /proc/xenomai/sched that the effective priorities are
>> what you expect ? Do you see mode switches while running your test
>> program ?
>
> I suspect you are still passing std::strings as arguments and RTT::Logger in
> your callbacks? They you are not running real-time any more. So I guess the
> priority you defined doesn't matter any more.
>
> Try using int's and a buffered data port to a third component to do the
> RTT::Logging. Then your priorities should be respected.
I can hear another vote for the rt-logger framework coming :-)
Peter
Fwd: Event emitted multiple times is lost in event queue
On Oct 8, 2009, at 17:02 , Peter Soetens wrote:
> On Thu, Oct 8, 2009 at 15:51, Butch Slayer <butch [dot] slayers [..] ...>
> wrote:
>>
>>
>>>>
>>>> But if the priority of the "world" component is higher than the
>>>> priority of the "Hello" component, why is the "World" component not
>>>> woken up when the "Hello" component emits an event?
>>>>
>>>> In this case it shouldn't be a problem that the event queue can
>>>> only
>>>> contain one event per event type. The "World" component should be
>>>> rescheduled when an event is emitted. But if I run this program
>>>> under
>>>> xenomai, I only see the first event, the second event is still
>>>> lost.
>>>
>>> The only reason can be that the rescheduling did not happen when we
>>> raised the semaphore on which the high priority thread was blocking.
>>> Dit you check in /proc/xenomai/sched that the effective priorities
>>> are
>>> what you expect ? Do you see mode switches while running your test
>>> program ?
>>
>> I suspect you are still passing std::strings as arguments and
>> RTT::Logger in
>> your callbacks? They you are not running real-time any more. So I
>> guess the
>> priority you defined doesn't matter any more.
>>
>> Try using int's and a buffered data port to a third component to do
>> the
>> RTT::Logging. Then your priorities should be respected.
>
> I can hear another vote for the rt-logger framework coming :-)
Yeah, yeah, yeah ... I get it ... I'm on the hook. v2.0 releasing Dec
31, 2009 ... right ... ? ;-)
S