Task Scheduling

Is this a hypothetical question?

Call a yield function within the tasks at an appropriate place, or possibly Delay( 0 ), to force it to swap out.

Alternatively design your application differently or use a different OS.

Regards, Richard.

Round-robing is not necessarily exclusive of preemptive scheduling. Don't know you mean.

Implement pre-emptive, round-robing scheduling using the timer interrupt. Allocate even number of quanta to each task.

-Le Chaud Lapin-

A bad idea. Preemptive scheduling takes more resources and more cpu time, and now you want to spend additional resources on this ?

Rene

Who told/taught you this ? I don't really see where it should end up needing more resources .

If you only have two tasks you don't really need an OS.

Ian

In my experience, those who ask this kind of question are unfamiliar with multi-threading techniques and the concept of efficiently sharing a processor while waiting for an event.

Round robin time-slicing is used by those who would poll (busy wait) instead of blocking. Blocking involves knowledge of OS primitives such as semaphores, and often involves interrupts at the system and hardware level.

This is a concept barrier that many embedded newbies need to overcome when moving to an RTOS environment.

Well, with cooperative scheduling, you don't have to protect shared variables with semaphores, since you know when the task is switched if at all. It switches only at the waits for resources. Here you only have to consider interrupts. Whereas a preemptive system constantly is in the timer interrupt. Each semaphore takes cycles as well as RAM.

Rene

You don't have to protect shared variables with semaphores in a preemptive system either, if you structure your code right, and the system provides appropriate guarantees of atomicity for certain memory operations. It is a common way to avoid embarrasment when you can't be sure of either of those though, true.

It's only in the timer interrupt when it's in the timer interrupt, surely?

Also, timer interrupts aren't the only, or even the most common, causes of preemption.

Sure.

What preemption gives you back, in return for those explicit costs, is the ability for your background tasks to consume 100% of the available compute resources, and be as complicatated and irregular as you like, without seriously affecting the event(interrupt) latency of your time-critical threads. Cooperative systems are great for throughput processes, but rather tricky for complicated real time ones, and you find (well, I have found) that you end up spending far more cycles testing the state of timers with conditional yield() calls, or sitting in spin-loops waiting for the periodic event to actually occur, than you would ever lose to the known overheads of preemption.

Your milage may certainly vary. There are indeed many systems and problems that have no "background" tasks to worry about, or which have no trouble partitioning those into work-units that won't blow out a timing constraint. You just have to know when you're in one of those happy situations.

Cheers,

The pre-emptive systems I am used to, do not use semaphores or global variables.

If you wait for a resource, you need to protect variables as well, since another process not waiting may access it in the meantime. Or you have to be very carefull during the design.

No. A pre-emption may take place because a timeout expires, but mostly it happens because an external event (I/O, ADC) made an interrupt.

Also, I think, if you have to add more jobs to an existing cooperative system you are more likely to get in trouble than with a pre-emptive system, which will eat up the benefit of the lesser ram real fast.