sched_yield() function / kernel call (I don't know about other systems, I'll explain on Linux example here)
(I didn't RTFS, maybe it's implemented already, but if not, it would be very nice)
Causes the task to abandon current run and pass control back to kernel, getting rescheduled at the end of the cycle.
Say, you have 2 tasks. One of them polls keyboard and displays status messages on LCD, the other performs some important, CPU-intensive function, i.e. some data conversion. It is desired that task 2 takes as much CPU time as possible, while task 1 requires really little of CPU time on usual basis, although it has short bursts when it needs some more (performing display update, interpreting the key if pressed)

The usual _BAD_ loop in C on Linux for task 1 would be

while( !display_needs_update && !key_pressed){}
... /* do other stuff */

which if given 256 cycles, wastes them polling the input, for which the chance to change within that 256 cycles is minimal, and prevents other tasks from using them in more reasonable way.

The better way would be:

while( !display_needs_update && !key_pressed)
{
sched_yield();
}
... /* do other stuff */

Everytime the conditions aren't fulfilled, the task gets normally rescheduled at the end of the queue as if it ran out of time, donating all its remaining CPU time for other tasks. They take some time, in the meantime the conditions might have changed, in which case our task would perform its (larger) work during the next call, or if the conditions are still the same, the task would just quickly evaluate them and pass the control over to the others again.

Possibly this could be done by setting task's own timeout timer to "nearly overflown" value, but this could destroy different timing mechanisms, so care should be taken.