[LITMUS^RT] LITMUS RT on Odroid Xu4 platform

sobhan niknam sobhan.niknam at yahoo.com
Wed May 29 18:00:08 CEST 2019



> On 29 May 2019, at 14:08, Björn Brandenburg <bbb at mpi-sws.org> wrote:
> 
> 
> 
>> On 29. May 2019, at 12:28, sobhan niknam <sobhan.niknam at yahoo.com> wrote:
>> 
>> I have encountered with a transient problem when I run an application with parallel real-time tasks using pthreads. Sometimes the tasks’ job are not released in correct time. You can see the problem in figure below, the second job of the last task is released at 13ms instead of 10ms!
>> Do you have any idea where this problem comes from?
> 
> Hi Sobhan,
> 
> no, sorry, I don’t. And how should I? I don’t know which plugin you are using,

I am using PSN-EDF

> I don’t know your application, I don’t know what code you are running,

My application is mjpeg that has 6 parallel tasks implemented with pthreads with similar structure as base_mt_task.c

> I don’t which facilities you are using to create your real-time threads and control their timing, etc. From just one figure, it’s really hard to guess as to what might be going on. 
> 
> Just looking at your figure, though, one can see that mjpeg/32084 self-suspends shortly after its first release, and that it doesn’t resume until shortly before time 13. LITMUS^RT interprets a thread’s self-suspension that exceeds past the thread’s current deadline/next-earliest-release time as a new job release. Put differently, why would you expect a job release to occur while the thread is not runnable? If you want that behavior, you need to use periodic polling reservations in the P-RES plugin. 

I exactly used the same structure as base_mt_task.c to create the threads, setup tasks parameters (real-time periodic tasks), and invoke real-time jobs of the threads for mjpeg application. However, this implementation sometimes works successfully and sometimes fails due to self-suspention, I don’t know why, and the tasks’ job are not released at correct expected moments!

Best Regards,
Sobhan

> 
> - Björn 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20190529/0a618401/attachment.html>


More information about the litmus-dev mailing list