[CppCon 2016] The speed of concurrency - note

Reference:
The speed of concurrency:
https://www.youtube.com/watch?v=9hJkWwHDDxs
The Art of Multiprocessor Programming

Easy to say but performance hit in reality (trade-offs):
Don’t communicate by sharing memory, share memory by communicating. (Golang)

Rule of performance

• Never guess about performance!
• Measurements must be relevant

Lock-free algorithms do not always provide better performance,

due to it might fall into forever wait, e.g CAS.

Wait-free programs

Each thread will complete its task in finite number of steps (finite amount of time) no matter what other threads are doing.
At all times, all threads make progress toward the final result “Step” is not the same as “time”

Lock-free programs

programs without locks (duh!); at least one thread makes progress no matter what other threads are doing.

Lock-based programs are not guaranteed to make progress toward the result in all cases.

In particular, consider what would happen if the thread holding the lock is waiting on another lock? That was held by the first thread?

Wait-free (or lock-free) does not mean “data-sharing-free”

Entire program is rarely wait-free or lock-free, focus on most performance-critical fragments.

http://vsdmars.blogspot.com/2021/03/go-methods-for-lock-starvation-barging.html

https://medium.com/a-journey-with-go/go-mutex-and-starvation-3f4f4e75ad50

https://vsdmars.blogspot.com/2018/09/c-something-about-spinlock.html

https://stackoverflow.com/questions/62318642/should-combining-memory-fence-for-mutex-acquire-exchange-loop-or-queue-acquire

https://www.realworldtech.com/forum/?threadid=189711&curpostid=189723

std::atomic_flag

https://en.cppreference.com/w/cpp/atomic/atomic_flag