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.
behaviour of chMBPostNN
- Giovanni
- Site Admin
- Posts: 14458
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: behaviour of chMBPostNN
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
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
Re: behaviour of chMBPostNN
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.
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.
keep cool
- Giovanni
- Site Admin
- Posts: 14458
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: behaviour of chMBPostNN
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
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
Re: behaviour of chMBPostNN
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
- Site Admin
- Posts: 14458
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: behaviour of chMBPostNN
faisal wrote: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
Who is online
Users browsing this forum: No registered users and 4 guests