As far as I know, the network must use the low-priority workers.
I can see a comment in arch/arm/src/stm32/stm32_eth.c line 88.
But I also remember reading somewhere that the high priority workers may
cause dead-locks.
But I think that the difference between the two workers is only the...
priority.
I guess that someone could easily swap their roles but adjusting the
priorities.
The high priority work queue was intended only to serve as the back end
for interrupt handlers: If interrupt handling needs more extensive
processing, then most of the interrupt processing can be off loaded to
the high priority work queue.
In order for the high priority work queue to be able to do that job:
1. It must be IDLE most of the time. If it is busy processing a lot of
nonsense, then back end interrupt processing will be deferred and
probably cause bad behaviors for the system
2. It must be VERY high priority. The default is 224. I would use 255
(maximum priority). Nothing must prevent the high priority work queue
from running and finishing interrupt processing.
Unfortunately, the high priority work queue gets over-used for other
things and often interferes with its primary purpose of servicing
interrupts.
The low priority just run a a priority similar to most task. it
defaults to a priority of 100. It is intended as a convenience for when
you just need to do a small something on a thread. It is not intended
for extended processing and things running on either queue should not block.
Care should be used when using either work queue. The are not real time
friendly. Things deferred to a busy work queue will happen at some
random time after queuing and that random time can be quite large.
I don't know if this is valid syntax, but the low priority work queue
should have a priority range in the Kconfig like:
range 1 (SCHED_HPWORKPRIORITY-1)
Which raises the question: what is a "high" priority?
The low-priority workers shall have a priority less than what?
The absolute value of a priority is irrelevant. Higher priority threads
run before lower priority threads. The absolute numeric value of the
priority does not affect when the task runs, only its relative priority
to the priority of other threads.
For example, I have several tasks (that use the network) running at a
priority of 100.
For various (irrelevant) reasons I raised the LP workers to 105.
Is this correct, or can it cause problems?
In general, which tasks must run at a higher priority than the LP work?
*(I am working on an STM32F4, if it makes any difference)*
This is really outside of the scope of the OS. There is no OS imposed
rule about what priorities you should use for your applications or for
the low priority work queue. So I don't think there is a rule or a
correct answer. You just need to experiment and tune your system so
that it behaves as you like.
A couple of other interesting thing about the lower priority work queues:
- You can have multiple low priority work queues. The are maintained in
a thread pool and can service multiple lower priority work requests
concurrently. You might need multiple low priority work queues if there
is a possibility that one may block or delay and constipate one work queue
- The lower priority work queue is intended for use only within the OS.
There is also a user space work queue that uses only standard POSIX
application interfaces and so it more suitable for use by applications.
