So if I understand correctly, to your 1st point, the qUpperBound() performs a binary search over the list stopping when a certain threshold is matched.
I assume the binary search might be a binary bisection, and therefore faster than say a linear search?
So the idea here is to assign a queue element a priority at the time of appending to the list in the producer, and then iterate from high to low in the consumer. Is there any downside to a QList vs. a QQueue as the collection class?
Our application would be a user space application with all long lived threads, nothing dynamic. Some of the embedded commercial vendors are suggesting that they might support differing task priorities, but I need to confirm this.
Looking into the Qt source code, it appears that the user argument on thread priority is being passed to the underlying POSIX threads, but the Qt documentation and other user experiences seems to suggest that the
priority value is somewhat meaningless. Of course, this might apply to desktop Linux only, and not the customized kernels tailored for real time Linux.
I think it does suggest, that modelling our final product on say desktop Linux prior to selecting an embedded board could be problematic, or at least we know there will be a lack of fidelity on task priorites and other.
Thanks for the suggestions as always ... wysota to the rescue again!
Added after 4 minutes:
I did not completely answer your question, we have a need to prioritize tasks based on what they do, and the data they handle. It is not a matter of saving resources. There will be high priority data to low priority data. For example, the priority of a task that writes to the USB will be lower than say one that writes content to the Ethernet or serial interfaces.
Bookmarks