behaviour of chMBPostNN

[cpucooler]

Hi folks,
just to be clear...
Doesn't chMBPostTimeout be a fire and forget? Like push message on q and continue?
In my application it seems, that chMBPostTimeout directly switches threads and the thread, which is waiting on chMBFetchTimeout, continues instantly.
I am somewhat confused.

Thanks in advance and best regards.

[Giovanni]

Hi,

It depends on relative threads priority, if the fetching thread has higher priority then it is immediately switched-in.

The general rule for this (and most other RTOSes) is: the highest priority ready thread is the one being executed.

Giovanni

[cpucooler]

Hi Giovanni,
thanks for answering.

So chMBPostTimeout ends in the scheduler and I can only avoid thread switching by lowering the priority of the receiving thread.
What's the behaviour if all threads have the same priority?

Thanks and best regards.

[Giovanni]

Hi,

Threads at same priority are "lazy" scheduled, the fetching thread would not be immediately rescheduled unless its time slice is over.

Anyway, better do not rely on scheduling and relative priorities, this is a recipe for hard to debug problems. There are better approaches to your problems.

Giovanni

[faisal]

One time I wanted to push a bunch of objects into the queue, and only after that allow the scheduler to switch threads (to avoid the context switch overhead). Otherwise if the consumer is higher priority, then everytime you push an object it will context switch. The trick was to use I-class APIs related to the queue, and then do a reschedule at the end after you're done pushing.

[Giovanni]

One time I wanted to push a bunch of objects into the queue, and only after that allow the scheduler to switch threads (to avoid the context switch overhead). Otherwise if the consumer is higher priority, then everytime you push an object it will context switch. The trick was to use I-class APIs related to the queue, and then do a reschedule at the end after you're done pushing.

Correct approach, make sure to do that within a lock zone.

Alternatively use a queue fetching with TIME_IMMEDIATE, this way it does not wait inside. Push al objects in the queue then signal/reset a semaphore or use an event to start the fetch thread. This does not require long critical section.

Giovanni