idea: lockfree?

[ghost]

Hi,

Any reason to have done a mutex + cond. variable manually?

Is there a rationale why you didn't go lockfree with (yes, possibly a mutex on linux) std::atomic::wait?
I think I will dive into that. But before I do, I would like to hear from you/anyone on that matter.

I am just too lazy to fork TBH.

Thanks

[David-Haim]

Can you point out which class are you referring?
Some functions in concurrencpp are pure lock free, most functions are hybrid, some functions use locks.
Lock free doesn't necessarily mean "faster" especially if the code in question is not in a hot path.

[ghost]

Sure!
your worker_thread_executor, thread_pool etc..

I will find the time to modify the code to be completely lock free, but on Linux and using gcc 11.
Then I will sanitize and compare to see if perf is better.

Action.

[David-Haim]

Re-implementing the threadpool executor with a lock-free algorithm won't have any effect.
The threadpool prevents contention by doing 2 things:
non threadpool threads are spread across threadpool-workers using the enqueue algorithm.
threadpool-threads enqueue tasks to a private queue, which doesn't need any synchronization at all.
So there is no lock-contention to begin with, and no real benefit of writing a lock free version of it.

If you have interesting benchmarks with a lock-free version of concurrencpp executors, feel free to share them in the PR and I will surely look at them.