Lock-free Data Structures Part 1 – Introduction | Hacker News Reader

Lock-free Data Structures Part 1 – Introduction

kukuruku.co

69 pointsadamnemecek17 comments

Can someone explain to me how the first queue example's (using singly link lists) dequeue method gives the expected result? Isn't head->m_pNext always NULL, so the new head will always be NULL and tail will be set to NULL losing the rest of the queue?

Seems like you should need to traverse the list to dequeue.

Where did I go wrong?

You're right. Enqueue is wrong, it should be:

    if ( !m_pHead )
        m_pHead = p ;
    else
        m_pTail->next = p;
    m_pTail = p;

For some reason, the author is inserting the node in front of the tail leading to the error.

The complex version doesn't even alter m_pHead in enqueue().

I have to say that even though it is nice to write about lock free algorithms, it would be probably worth noting that this implementation is dismissing the problem of CPU caches which eventually and most likely lead to race conditions.

What kind of race conditions are you talking about? Something along the lines of memory access that causes the CPU caches to be purged a lot more than they normally would? Genuine question, I know little about CPU cache internals :)

Out of order execution and possible cache consistency issues can cause your careful order to be upset.

The solution is memory barriers:

http://en.wikipedia.org/wiki/Memory_barrier

That's the point of this post (well, the second I guess) - the lock free version has those via atomics.

So CDS_ATOMIC:: and friends expands into barrier instructions that take care of both re-ordering and cache consistency issues?

edit: reading the http://en.cppreference.com/w/cpp/atomic/memory_order there is tons of data on re-ordering but nothing on cache consistency so I am assuming that's a job farmed out to the hardware somehow.

In that case ignore above comment :)

I don't know if this implementation got it right (I don't have a spare month to prove/disprove its correctness)but my advice would be: be very, very careful with lockfree code in C++. This the area where dragons live.

Let me cite Herb Sutter: "Second, it's hard even for experts. It's easy to write lock-free code that appears to work, but it's very difficult to write lock-free code that is correct and performs well. Even good magazines and refereed journals have published a substantial amount of lock-free code that was actually broken in subtle ways and needed correction.

To illustrate, let's dissect some peer-reviewed lock-free code that was published here in DDJ just two months ago [2]. The author, Petru Marginean, has graciously allowed me to dissect it here so that we can see what's wrong and why, what lessons we should learn, and how to write the code correctly. That someone as knowledgable as Petru, who has published many good and solid articles, can get this stuff wrong should be warning enough that lock-free coding requires great care."

For the curious, that's from here:

http://www.drdobbs.com/cpp/lock-free-code-a-false-sense-of-s...

So if not C++, then C? Exist a good library of lock-free?

http://www.liblfds.org/

Ok. Thanks.

P.D: Weird github use:

https://github.com/liblfds?tab=repositories

Cache coherency isn't something that average app developers have had to worry about since forever - the only place I can think of most developers might encounter issues is with GPU programming, but graphics APIs tend to deal with coherency issues pretty well.

Jacques said "consistency", not "coherency"… those are different things.

Yes, most processors provide a coherent cache – individual writes are guaranteed to be eventually seen by all cores. However, most modern processors do not provide a consistent cache (for performance's sake): the order that unrelated writes become visible is not guaranteed.

Memory fences (which are not flushes or invalidates; neither implies the other!) instruct the CPU to provide such ordering.

It seems like HN took the site down, here's the Google cache

http://webcache.googleusercontent.com/search?q=cache:kgO8-Tc...

Rule n° x: turn display_errors off and log_errors on.

Reply on news.ycombinator.com