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).