On Tuesday 06 July 2004 06:42, Tim Blechmann wrote:
SCHED_RR and SCHED_FIFO are close. I think the only difference is if the tasks have the same priority, then maybe SCHED_RR actually starts time-slicing. But don't take my work for it, look it up :-)
that's correct ... if there are two threads (a,b) with the same priority, SCHED_FIFO will cause that the first of these thread will run until it's finished or sleeping, then the second thread can start (aaaaaabbbbbb). SCHED_RR will cause to run both threads for small timeslices (ababababab)... but afaik, it only has an effect if both threads are using the same priority, so with pd, i don't know if there is an effect when using -rt.
I suppose it could matter if there is an other application running one of its threads SCHED_FIFO with the same priority.
if there are two threads, one having a high priority (reniced by -rt) and one low priority there would be no difference ...
Please don't say that "-rt" "renices" the thread. Unless I'm mistaken, the "nice" setting only applies to non-realtime threads. It is a different scheduling policy entirely. Try looking at the "nice" value of PD threads in "ps" or "top" for example. It won't make any sense, because its value is not used by the POSIX soft-realtime scheduler.
another feature of the -rt mode is the memory locking ... it's enabled on machines, where _POSIX_MEMLOCK is defined (at least on linux it is). this will force the memory to be represented in the physical memory. (one will not be able to allocate more memory).
I thought that the memory locking was done by a seperate system call, and that setting the scheduling policy to SCHED_FIFO or SCHED_RR by itself did not lock memory. Also, you can still allocate memory after making this call. I had assumed that if you use memlockall (or however it's spelled), that any memory allocated after the call will also be locked (is this correct?)
Larry