<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 10, 2021 at 9:58 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 10/06/2021 16:24, Gedare Bloom wrote:<br>
>>> 5. Can anyone give some suggestions to solve the problem? thanks!<br>
> Classic and POSIX APIs can be mixed. It is a poorly documented benefit<br>
> of RTEMS. I think in this case, you should be able to use<br>
> pthread_setschedparam(...) with passing policy == SCHED_RR to get the<br>
> behavior you seek. You have to use posix priorities in the sched_param<br>
> argument. though, or else your thread will have its priority changed.<br>
> Pass the task_id instead of pthread_t as the first argument, and the<br>
> rest should work itself out. Do let us know if that works or it<br>
> doesn't work/you have more questions.<br>
<br>
You can use these directives to convert priority values:<br>
<br>
<a href="https://docs.rtems.org/branches/master/c-user/scheduling-concepts/directives.html#rtems-scheduler-map-priority-to-posix" rel="noreferrer" target="_blank">https://docs.rtems.org/branches/master/c-user/scheduling-concepts/directives.html#rtems-scheduler-map-priority-to-posix</a><br>
<br>
In general, the timeslicing based on clock tick quantum is quite coarse. <br>
The internal timestamps would allow a much finer grained timeslicing. <br>
This could be added if someone is interested in a small project.<br></blockquote><div><br></div><div>TImeslicing accounting requires something to invoke the update method.</div><div>The only "trigger" is the clock tick. Turning the tick quantum down doesn't</div><div>add a lot of overhead. One millisecond is certainly not an issue on even </div><div>low end hardware. And then have a timeslice of 1 tick.</div><div><br></div><div>Also the timeslice value is the same across all threads.</div><div><br></div><div>If you are depending on timeslicing in your application to share the CPU</div><div>across threads, then you probably should at least consider why they are</div><div>using that much uninterrupted CPU time and ensure you have accounted </div><div>for that in your design.</div><div><br></div><div>--joel</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-- <br>
embedded brains GmbH<br>
Herr Sebastian HUBER<br>
Dornierstr. 4<br>
82178 Puchheim<br>
Germany<br>
email: <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
phone: +49-89-18 94 741 - 16<br>
fax:   +49-89-18 94 741 - 08<br>
<br>
Registergericht: Amtsgericht München<br>
Registernummer: HRB 157899<br>
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler<br>
Unsere Datenschutzerklärung finden Sie hier:<br>
<a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a><br>
_______________________________________________<br>
users mailing list<br>
<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/users</a></blockquote></div></div>