Re: how to avoid/resolve priority inversion.

> 
> 
> >> 
> >> I am using mbuff to realize the communication between real-time task and no real-time task in rtlinux3.0 .Both  real-time task and no real-time task  can  read or write the mbuff .
> >> In order to guarantee the integrity of data in mbuff ,the semaphore has been usded.
> >> However,the priority inversion may  happen in this case.Does anyone know how to avoid/resolve priority inversion in this case.
> >> Thanks in advance.		
> >>
> >you can use sequence locks on the non-RT side to ensure that the RT-task is 
> >never blocked by the non-RT task. sequence locks are implemented in the 2.6 
> >series of kernels and you can more or less take the code from there with 
> >the only modification being that the sequence would have to be stored in 
> >a shared memory location.  
> >
> >hofrat
> I don't know much about sequence locks.but I think it will  work well if there is no logic relation between RT-task and non-RT-task.In our system,the RT-task have to  read command  from the mbuff to decide its next action.the command is assigned  by user through non-RT task.If the non-RT task is blocked too long for some reason(such as other non-RT task or RT-task which have higher priority),the deadly thing will happen.So ,I need a mechanism to help  the non-RT task to execute as  soon as possible .I think the priority inheritance is a good method. But ,unfortunately ,RTLinux does not support priority inheritance.Is there any other effective method to resolve it in rtlinux? Thanks a lot.
>
Not sure if I understood your problem correctly but this
simply means that you are doing some processing with hard-realtime demands
in user-space/Linux-context that actually need to be done in RT-context - so 
basically this sounds like a design problem - where are the commands being
read from - user-input, processes or file ?

Also RTLinux actually does support priority protection (see rtlinux 
configuration -> POSIX_THREAD_PRIO_PROTECT ), but that would hardly solve
your problem as priotiry inheritance/ceiling protocols are inherently non-RT
(they only prevent deadlock but the delays are not bounded - and definitly
the use of priority inheritance/ceiling will break any realtime constraints)
Naturally priority protection can't extend into Linux - this would require
to raise the priority of Linux to that of the RT-task which would eliminate
the purpose of rtlinux more or less.

hofrat 
_______________________________________________
Rtl mailing list
[email protected]
http://www2.fsmlabs.com/mailman/listinfo/rtl