scheduling policy

Thanks for the input, everyone. I'm experimenting with round robin scheduling as a quick way to see preemption at work in uClinux. I've worked with vxWorks in the past so I'm pretty familiar with the basics but haven't been under the hood on a Unix derivative and haven't used POSIX threads either, so before diving in to the real project I wanted to familiarize myself further.

roddy says:

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

1: Round robin scheduling won&#39;t switch between tasks except at system "clock tick" boundaries. which are typically about 100Hz. So to see RR scheduling happening, you need to make your task busy for at least 10Millisecs. This is more than just a little bit of maths and declaring an int. Try calculating PI to 1000 places with floating point math cool.gif ? You only need RR scheduling if you have more than one *CPU-bound* task at the same priority level.[/b]

--- Quote End ---

That did the trick! (well, I didn&#39;t calculate PI but inserted a loop of floating point math to slow things down) Not only was I underestimating the processor speed, but I also hadn&#39;t checked the actual time a single process is allowed to run before being preempted by a process of the same priority (sched_get_rr_interval() return value). On our system it&#39;s 100 milliseconds, ten times the clock tick.

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

2: Putchar and buffering. Even if you&#39;re using a slow serial port, putchar will likely put some buffering in the way, so your output will happen quicker than it appears. This can distort what you see.[/b]

--- Quote End ---

Indeed, and as a result I haven&#39;t concerned myself about how soon the output appears but just its order. Since stdout has a single buffer to which all four threads are writing (threads share file descriptors), buffering shouldn&#39;t affect the order.

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

2: Beware the priorities of your spawned tasks vs. the task spawning them! Make sure your spawned tasks don&#39;t start running until all of them are ready to go, otherwise you&#39;ll get additional confusion. This is why you see the slightly odd starting and ending sequences with the &#39;yield&#39; inserted.[/b]

--- Quote End ---

Threads inherit their parent&#39;s priority, and pthread_create starts running the thread right away, so the eccentricity of the ordering at the beginning and end didn&#39;t surprise or alarm me. Putting a barrier at the start of the thread processes would fix it.

wentao says:

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

Here [in sched_setscheduler()] 0 means current calling process instead of root process.[/b]

--- Quote End ---

Oops. I missed that sentence in the man page, but now see it. Thanks, and I see the same is true for sched_getparam(), sched_getscheduler() and so on.

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

why do you expect the second to preempt the first one? All the five thread you have are of the same scheduler policy and the same priority.[/b]

--- Quote End ---

I expect it because that what&#39;s SCHED_RR (round robin) scheduling is supposed to do: enable time sharing between processes of the same priority. SCHED_FIFO, on the other hand, does not timeslice between processes of like priority.

Again, thanks for all the help. On to the next thing.