Re: [Looking for Feedback] - Fairness lib

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2023-10-21 16:27:56

On 10/21/23 17:11, Federico Abrignani via Boost wrote:
> Dear Boost Community,
> 
> 
> I am writing to seek feedback on a new C++ library that I have been
> developing (https://github.com/Sernior/fairness
> <https://github.com/Sernior/fairness>).
> This library, named "*Fairness*," is still a work in progress.
> Nonetheless, I believe that this is an opportune time to begin gathering
> feedback.
> 
> *Fairness* is designed to provide fair synchronization primitives. While
> the standard C++ library offers various tools for managing concurrency,
> it does not provide mechanisms for handling fairness policies.

[snip]

> The primary motivation behind creating this library is to enhance
> throughput in multi-threaded pipelines.
> To illustrate the concept more simply, imagine a pipeline with N tasks,
> some of which access a protected resource.
> In cases of contention, there exists an optimal order of resource
> accesses that minimizes overall execution time,
> https://sernior.github.io/fairness/
> <https://sernior.github.io/fairness/>Â the images show 2 different ways
> of ordering critical sections one of which is much better than the other.
> 
> This library aims to empower developers, who have profiled their
> software, to manipulate this order with minimal performance overhead and
> as simply as possible.

While I do think priority-based synchronization primitives would be a
very useful addition to Boost libraries, I find this motivation
puzzling. Priorities are introduced to avoid starvation of specific
(high-priority) threads at the expense of the less important threads and
likely overall performance (because fairness is not free). The chart you
show on the front page is nice, but it seems to me like a hand-tailored
case that is not necessarily related to reality. 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).