Latencey in activating a thread after posting event

I’m working in a project where MBED OS is used as part of Arduino Core (the pro series of MKR boards). A couple of coleagues have worked on it before me, but none of us had previous experience with MBED nor RTOS before. Nontheless, the complexity of the project needed an RTOS so we decided using Arduino boards with MBED. But I am alone now with no coleagues to work with.
I’m facing an issue that was supposed to be done the right way but nobody here was able to learn and use the DMA. So we used a thread to run a queue where a couple of method are posted as events. A ticker post the event on the queue at regular intervals. I measured the sampling period that the execution of the callback implements, but I realized that i do not get a regular period of 80us. I get deviations up to 150us. I also measured the period of the ticker isr posting the event, and it is much predictable with no more than 85us of deviation.
In a far future I plan to migrate to a sample rate based on timers and DMA but I have no time to learn and experiment all that.

So I wonder how can I make the thread active with a lower latency after posting the event on its queue. My goal is getting an execution of the callback as close as possible to the ticker periodicity. I guess the context switching or whatever other rtos processes are delaying the activation of the thread even though I have it configured with a high priority.

Obviously with little experience, i still don’t undestand well the MBED framework, how the scheduler works and stuff. I need one thread to be hard-real time, but the rest could be soft realtime.
What i guess should be possible is that the posting of an event to the highest priority thread could cause the immediate context switching so that the latency to the activation of the thread is as low as possible, less that 1us ideally.
Another idea I have is somehow blocking the scheduler after and event happens so as to just run the thread to completion. But I’m not sure it is possible or recommended.

Any idea of how to get one thread running as real-time as possible will be much appreciated.

Is it possible that the MCU is going to sleep? Waking up from sleep or deep sleep can take 100s of microseconds, or more. Generally Mbed MCUs will go to sleep if no threads are able to execute.

Hello Jamie
Not a bad idea to check that, but my latency is around decades of us and it is almost always present somehow stocasticly distributed around 10us in excess.
We are not activating on purpose any sleeping mode either