I don’t know what the result of sleep(0) is in QNX 6. At best it would do the same as sched_yield(). At worst it will do nothing. But you have a bigger problem. Neither of these solutions is likely to get the result that you want. Assume for a moment that you only have one cpu available and consider three questions about the threads that this thread will be competing with.
- What priority will they run at?
- What scheduling method do they use?
- What is their cpu usage profile?
If you are only running against a thread at a higher priority you can safely change your code by removing the sched_yield()/sleep(). The higher priority thread will take control whenever it wants to. But if that thread is also in a busy loop, your thread will get no cpu regardless of what your code looks like. So in this case calling yield just wastes time with re-scheduling.
If you are running against a thread at a lower priority, your thread will never give up the cpu to that thread. Calling sched_yield() will cause the kernel to reschedule, but since your thread is still ready and at the top of the queue, it will continue to run. This of course makes no sense.
Your thread runs at the same priority as another thread, either one runs using sched_rr scheduling and the other thread hogs the cpu.
In this case, the following behavior occurs.
Your thread runs for one loop
The other thread runs for one time slice
This at least has some identifiable purpose, but can be implemented in a much more elegant way.
Run your thread at a higher priority, and use a timer to wake it up at whatever period you want to check the condition.
Your thread runs at the same priority as another thread, either one runs using sched_rr scheduling and the other thread does not hog the cpu.
Your thread runs for one loop
If READY the other thread runs for one time slice or until it is done.
This at least might make some sense if you want your thread to be checking the condition unless the other thread is running, but also guarantee at least one check per time slice. A better solution is for you to run two threads. One lower priority thread checks the condition in a busy loop, but also resets a timer each time it checks. The other higher priority thread waits for the timer to fire, checks the condition and also resets the timer. This way, you decide what the minimum periodicity of the check is. If you think about this carefully, it isn’t the exact same behavior, but that too could be implemented if you really want it.
Your thread runs at the same priority as another thread, both run using sched_fifo scheduling and the other thread hogs the cpu.
Now you get this obviously useless behavior.
Your thread runs for one loop.
The other thread runs forever.
Your thread runs at the same priority as another thread, both run using sched_fifo scheduling and the other thread does not hog the cpu.
If the other cpu never uses a whole slice, this case is the same as case 4. If it does, then it is the same as case 3.
This is all complicated enough, but there are other parameters that you can consider. Do you have more than one cpu? Are you running AP?
Even so, I can’t think of any situation in which you would want to do what you are doing.