Re: [Looking for Feedback] - Fairness lib

From: Federico Abrignani (federico.abrignani_at_[hidden])
Date: 2023-10-21 18:03:42

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

Yes the charts I provide are a simple hand tailored case that I am using 
to explain visually a concept that may happen in the real world.

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

Right, but that is also why I said "After profiling your software".
There is no guarantee until a developer sees it happening.
Allow me to quote my own documentation:
"
These tools, if misused, have the potential to cause harm rather than 
benefit. Careful implementation and understanding are crucial to harness 
their benefits effectively.
"

What I meant with this sentence is exactly what you are saying:
These tools should be used by people who have first profiled their 
software and found themselves in the situation where they thought:
"If only I had a way to tell my threads that a specific task should be 
performed first ".

But I feel your concern as it is also my concern. I surely need to 
perform more studies to find out exactly the boundaries of when using 
priority mutexes is better than not using them.

If you are interested you can have a look at my pipeline benchmarks and 
tinker with them!

https://github.com/Sernior/fairness/blob/main/benchmarks/pm/priority_mutex_benchmark.hpp

 Â Â Â Â Â Â Â  std::array<int, 8> prios {0, 2, 2, 1, 1, 3, 3, 0};
 Â Â Â Â Â Â Â  std::array<int, 8> preCT {20, 15, 20, 30, 10, 5, 5, 20};
 Â Â Â Â Â Â Â  int CT = 10;
 Â Â Â Â Â Â Â  std::array<int, 8> postCT {50, 30, 20, 25, 10, 15, 15, 45};

these 3 arrays are the priorities, times before and after the critical 
sections for the 8 threads. CT is the time of the critical section.

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?

Feel free to contact me by email directly if you want some explanations 
on how to use my benchmarks!

Thanks for the feedback.

Federico Abrignani.