I read the article "Lock-Free Code: A False Sense of Security" by Herb Sutter and here are some interesting notes from it:
-The drawbacks of lock free code are that 1. it isn't generally useful for typical problems 2. it's really hard to implement.
-lock free variables must ensure atomicity and ordering
-In the code he dissects to show the issues with the lock free data structure, the problem does not arise in the general use scenario. If the producer and consumer used the queue the way they generally should, there would be no issues. But there is a possibility that you could write code to break it, which is where the issue arises.
colorblue
After reading "Common Pitfalls in Writing Lock Free Algorithms" it seems to stress what the other article stressed and Prof. Kayvon stressed at the end of this lecture. A common misconception is that lock free code means less waiting and forward progress at all times. However all that lock free code assures is that "there is an upper bound on total number of steps it must perform between successive completions of operations". This does not translate to performance. Lock-free data structures should be used in a case by case basis as writing them can be very hard to implement correctly and will not assure a performance boost. Their performance is often comparable to well written code with locks.
As mentioned in the article, it's possible to alleviate the issues caused by relaxed memory consistency if we ask the operating system to run threads on the same core. This means they'll see updates to memory addresses at the same time.
I read the article "Lock-Free Code: A False Sense of Security" by Herb Sutter and here are some interesting notes from it:
-The drawbacks of lock free code are that 1. it isn't generally useful for typical problems 2. it's really hard to implement.
-lock free variables must ensure atomicity and ordering
-In the code he dissects to show the issues with the lock free data structure, the problem does not arise in the general use scenario. If the producer and consumer used the queue the way they generally should, there would be no issues. But there is a possibility that you could write code to break it, which is where the issue arises.
After reading "Common Pitfalls in Writing Lock Free Algorithms" it seems to stress what the other article stressed and Prof. Kayvon stressed at the end of this lecture. A common misconception is that lock free code means less waiting and forward progress at all times. However all that lock free code assures is that "there is an upper bound on total number of steps it must perform between successive completions of operations". This does not translate to performance. Lock-free data structures should be used in a case by case basis as writing them can be very hard to implement correctly and will not assure a performance boost. Their performance is often comparable to well written code with locks.
For those interested in lock free memory allocation, check out this article - https://erdani.com/publications/cuj-2004-10.pdf
This post by Preshing offers a pretty great example of how relaxed memory consistency models can cause subtle issues in lock-free code:
http://preshing.com/20120515/memory-reordering-caught-in-the-act/
As mentioned in the article, it's possible to alleviate the issues caused by relaxed memory consistency if we ask the operating system to run threads on the same core. This means they'll see updates to memory addresses at the same time.