Arm Mbed OS support forum

Does the use of get methods in mbed RTOS bring task to waiting state

Hi all and thanks.

Well I’m working on a Mbed OS 6.2 course for my students.

I wonder ; does a task (thread) with a (for example queue) get method affect thread state (ie : if there is nothing to read does task goes waiting or is it just Round-Robin algorithm that swing thread from ready to running state?

and another question : how to disable a serial communication with TxIrq set, IRQ ?

Thanks to all.


I’m not sure that this is what you are looking for but it might help:

Default timeouts

The Mbed RTOS API has made the choice of defaulting to 0 timeout (no wait) for the producer methods, and osWaitForever (infinite wait) for the consumer methods.

A typical scenario for a producer could be a peripheral triggering an interrupt to notify an event; in the corresponding interrupt service routine you cannot wait (this would deadlock the entire system). On the other side, the consumer could be a background thread waiting for events; in this case the desired default behavior is not using CPU cycles until this event is produced, hence the osWaitForever .

Note : When calling an RTOS object method in an ISR, all the timeout parameters must be set to 0 (no wait); waiting in ISR is not allowed.

Could you please explain your question in more details?

Best regards, Zoltan

Thank you for your answer Zoltan.

Let me clarify.

In a RTOS when a task is “waiting” for something the scheduler doesn’t even try to give it a time slice (this is called waiting state) but when ressource is gained then task switchs to ready state and when scheduler give it a time slice then task switchs to running state. You can find this in thread docmentation.

My question is : does task involving a “infinite” loop waiting (for example like queue.get()) switch the thread that calls it to waiting state or is it a polling (scheduler give some time slice to the task in order to try to get) ? It’s unclear in the very reduced documentation of Mbed OS 6.

Is it also valid for a THREAD (not an ISR) that try_put() with a timeout>0?

For serial communication, my question was : if I activate the Buffer Empty interrupt of any serial communication (for example BufferedSerial.attach(…, TxIrq)) how can I disable the interrupt when there is nothing to transmit as there is no detach function. But I’ve seen in BufferedSerial that a NULL pointer in the attach method seems to be enought to disable IRQ…

By advance thank you if you find any interresting informations about wainting functions.