Re: [Xenomai-help] New scheduler class

[Jan Kiszka <jan.kiszka@domain.hid>]

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

Andreas Glatz wrote:
>>> Actually that is what I thought in the first place, however Jan's
>>> comment "That's not true, Xenomai threads can run in non-RT scheduling
>>> classes as well. They may just gain RT priority while holding some
>>> lock that is requested by a RT thread as well." made me think I was
>>> wrong...
>>>
>>> So we would really need a SCHED_IDLE for Xenomai then to solve this problem?
>> I don't think so. But we do need to solve the issue that a non-RT thread
>> stays too long in primary mode and is thus scheduled by Xenomai with the
>> wrong priority /wrt other Linux task at its level.
>>
>> For the time being, you can work around this by issuing a Linux syscall
>> before entering long processing loops - unless your task doesn't do this
>> anyway, e.g. to perform some Linux I/O.
>>
> 
> I think that's need. Currently the statistics task takes a mutex and waits on a message queue for messages. That's the only time it should potentially run in primary mode. After it returns the Mutex it should continue running with a policy similar to SCHED_IDLE to give other tasks a chance to run. I see how switching back to secondary mode could be achieved by issuing a Linux syscall. Is there another way which doesn't involve changing the source code of our application? (The proper way?)

The proper way would be to not having to change the application code.
But this workaround (Linux syscall or *_set_mode()) is required until we
improve the nucleus.

Jan


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