

Lock-free Data Structures Part 1 – Introduction - adamnemecek
http://kukuruku.co/hub/cpp/lock-free-data-structures-introduction

======
iano
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?

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

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

~~~
augustl
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 :)

~~~
jacquesm
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](http://en.wikipedia.org/wiki/Memory_barrier)

~~~
brigade
?

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

~~~
jacquesm
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](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 :)

~~~
pkolaczk
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."

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

~~~
jacquesm
[http://www.liblfds.org/](http://www.liblfds.org/)

~~~
mamcx
Ok. Thanks.

P.D: Weird github use:

[https://github.com/liblfds?tab=repositories](https://github.com/liblfds?tab=repositories)

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

[http://webcache.googleusercontent.com/search?q=cache:kgO8-Tc...](http://webcache.googleusercontent.com/search?q=cache:kgO8-TcOGGgJ:kukuruku.co/hub/cpp/lock-
free-data-structures-introduction+&cd=1&hl=en&ct=clnk&gl=us)

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

