I am having trouble understanding the scheduling of threads in QNX. In the most basic scenario, I have a thread, priority 255, FIFO scheduled, with a system tick of 100us. It does a nanosleep of 100us. It actually takes 217us. What this looks like to me is that the thread did not get switched back into context until the next kernel tick. But, I thought this was a pre-emptive RTOS. Which, in my experience, means that when a task is ready, it will be switched back in regardless of the position of the kernel tick. (Usually after most OS calls, the ones that cause scheduling shifts, the scheduler is run; not just on system tick intervals.)
Hum I though I already answered that.
The short answer is that this behavior is defined by POSIX. It says that a delay must be at least the requested delay + 1 system tick.
Ok, but do you know of a method I could delay my thread without incurring this penalty or busy looping?
A few methods that comes to mind.
The first is to set the tick to at least half of what you need but since it’s already at 100us I wouldn’t do it. In fact I would not use 100us for a system tick because that translate to 10000 interrupts a seconds.
The other solution is to use an interrupt of some kind. That depends on the hardware you have available. The RTC timer might do it, although I’m not sure it can go as low as 100us. If that is critical you can add a timer card.
There is this ibv-augsburg.net/en/timer.html never tried it myself.
Thanks mario. I appreciate your insight and suggestions. I’m not sure what I am going to do from here.
Any scenario is, when using a system with more then one processor/core, using a busy wait has less of an impact on the overall system. With a 4 cores system, a busy wait uses 25% of the total processing power.
I would guestimate that that on a dual core system the overall performance is going to be better if you busy wait for 100us once in a while, then trying to use delay and setup a very small tick size.