Timer thread priority

1

Dear MicroEJ,

I am currently facing an issue with a thread prioritization with the simulated execution engine.

My need is the following : I need to lower the priority of a custom Timer ( from 5 to 4 ).
After the schedule method from the TimerTask class is executed ( within the thread with priority 4), the run method is never executed.

From what I noticed using the thread stack traces, the thread is always in the state WAITING.

More interresting, when I quit the simulator, in my log console I saw that the run method of the corresponding TimerTask is finally executed.

Precisely :

  1. Simulator is launched :

(…)

The method schedule is executed…
>>> ServiceLoaderFactory.getServiceLoader().getService(AssistTimer.class).schedule(this.savingTimer, delay, period);

  1. The run method is NEVER called after the specified delay…

(…)

  1. I quit the simulator on my computer and then got the following line on my console,
    meaning that the run method is finally executed… :

ConfigurationManager.saveConfigurationInMemory(…).new TimerTask() {…}.run()

The behaviour on point 2 is not the same when the priority is set to 5 : the run function of the TimerTask is correctly executed after the delay.

Even more interresting : when I execute the same program on the target device, the run method is correctly launched with my thread’s priority set to 4… So the behaviour between both environment seems to be different

Is there a Thread on the simulator that does not exist in the embedded application, with an higher priority than the one I set to my Timer that prevents this one from being executed ? It could explain why the run method is finally executed after the simulator is shut down …

2

Hi Jean-Baptiste,

I confirm that that the simulation supports the threads priorities. We should try to understand why the timer is not scheduled? What does the timer do? Can it be blocked by another thread?
The fact that when stopping the simulation the thread starts is telling me that maybe the timer is blocked by something involving a mock [1]. Because we stop mocks before stopping the simulation, allowing the timer to really begin its execution.

Hope it’ll help.
Gaëtan

[1] https://docs.microej.com/en/latest/PlatformDeveloperGuide/mock.html

3

Hi Gaetan,

Indeed there was a problem with a mock service, which simply has a different behaviour on the target device.
Thanks for your reply and the document!

Jean-Baptiste