Running a Photon app at a real-time priority

What’s it like to run a Photon app at a real-time priority?
Does everything in the display system inherit that priority
while the real-time app is drawing? Is there a maximum latency
during which Photon can be busy with lower-priority work?
Thanks.

John Nagle

John Nagle wrote:

What’s it like to run a Photon app at a real-time priority?
Does everything in the display system inherit that priority
while the real-time app is drawing? Is there a maximum latency
during which Photon can be busy with lower-priority work?

When an app talks to Photon, Photon’s priority floats to the app’s
priority, just like any other resource manager, but Photon is just the
microkernel and doesn’t do much of the work itself. When you flush your
draw buffer, Photon will run at your priority to determine which regions
your draw event should be delivered to, and then pass copies of your
event to the app (or apps) that owns those regions. The event is
delivered in a reply (reading a Photon event is like reading data from a
pipe or socket), and the receiving app processes it at its own priority.
Photon events don’t carry any priority information.

Normally, the graphics driver runs at priority 12, and the window
manager at 10. Window manager requests are synchronous – pwm has to
actually ask Photon to reply to you, which means that a high-priority
app can be starved if something is running ready above pwm’s priority.
Also, if some apps do a lot of drawing and the graphics driver’s event
queue has reached its limit, Photon will “hold” any app that attempts to
add more events to the full queue, and the app will stay blocked until
the graphics driver gets enough CPU cycles to read some events from the
queue. The analogy with a pipe works here, too.

In short, it may be a good idea to run your realtime stuff in a separate
thread. Note that even calling PtEnter() in that thread may cause
priority inversion – if your Photon thread is in the middle of talking
to pwm, PtEnter() won’t return until after pwm is done processing the
request at priority 10.

Thanks. That’s about what I expected.

John Nagle

Wojtek Lerch wrote:

John Nagle wrote:

What’s it like to run a Photon app at a real-time priority?
Does everything in the display system inherit that priority
while the real-time app is drawing? Is there a maximum latency
during which Photon can be busy with lower-priority work?


When an app talks to Photon, Photon’s priority floats to the app’s
priority, just like any other resource manager, but Photon is just the
microkernel and doesn’t do much of the work itself. When you flush your
draw buffer, Photon will run at your priority to determine which regions
your draw event should be delivered to, and then pass copies of your
event to the app (or apps) that owns those regions. The event is
delivered in a reply (reading a Photon event is like reading data from a
pipe or socket), and the receiving app processes it at its own priority.
Photon events don’t carry any priority information.

Normally, the graphics driver runs at priority 12, and the window
manager at 10. Window manager requests are synchronous – pwm has to
actually ask Photon to reply to you, which means that a high-priority
app can be starved if something is running ready above pwm’s priority.
Also, if some apps do a lot of drawing and the graphics driver’s event
queue has reached its limit, Photon will “hold” any app that attempts to
add more events to the full queue, and the app will stay blocked until
the graphics driver gets enough CPU cycles to read some events from the
queue. The analogy with a pipe works here, too.

In short, it may be a good idea to run your realtime stuff in a separate
thread. Note that even calling PtEnter() in that thread may cause
priority inversion – if your Photon thread is in the middle of talking
to pwm, PtEnter() won’t return until after pwm is done processing the
request at priority 10.