Re: [Looking for Feedback] - Fairness lib

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2023-10-21 23:52:01

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.