On 10/21/23 21:03, Federico Abrignani via Boost wrote:
Specifically, there is no guarantee that processing times for different threads are aligned as depicted on your chart. For example, one of the threads could have a very long processing time compared to other threads, which would negate any effect on the total processing time from reordering threads using priorities. What priorities actually provide is minimize the processing time of the high-priority thread, pretty much regardless of the low-priority threads, barring data starvation, of course. So I think, you should probably reconsider the motivation or at least present some evidence that the library helps to achieve the stated goals in practice (and how does it do that).
But returning to your example, if one of the threads, lets call it *L*, has has a very *L*ong processing time compared to the other threads, wouldn`t you agree that it would be better if *L* had priority
over the other threads? If you wanted to finish as fast as possible the tasks of all threads?
No, not necessarily. It is usually not the matter of long or short run time, but rather what is the bottleneck or what is required to finish fast. To give an example, consider two threads. One is produces data and puts it in a queue, the other one dequeues the data and, say, writes it to a file or sends to network. Producing data is expensive, so the first thread may take a lot of processing to produce a piece of the data. Also, the queue has limited capacity and may overflow, in which case the writer will overwrite previously written data. In order to avoid that, you would typically prefer the second thread to have a higher priority, so that the enqueued data is dispatched ASAP and the queue is mostly empty. Doing so may increase the runtime of the first thread, as it may block on the queue for longer periods of time, especially if there are multiple readers. Surely, there is a wide variety of use cases, some of them are more along the lines of what you're saying. My point, though, is that priorities are not about minimizing overall run time, as your documentation suggests. They are primarily about minimizing starvation or minimizing latency of *specific* threads or tasks at the expense of other threads and general performance. Whether that effect is used to achieve correctness, reduce latency or improve throughput is application-specific.