5 ms·

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

by brigade 12y ago

jacquesm 12y ago
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 12y ago
  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."
  - jacquesm 12y ago
    For the curious, that's from here: http://www.drdobbs.com/cpp/lock-free-code-a-false-sense-of-security/210600279 http://www.drdobbs.com/cpp/lock-free-code-a-false-sense-of-s...
  - mamcx 12y ago
    So if not C++, then C? Exist a good library of lock-free?
    - jacquesm 12y ago
      http://www.liblfds.org/ http://www.liblfds.org/
      - mamcx 12y ago
        Ok. Thanks. P.D: Weird github use: https://github.com/liblfds?tab=repositories https://github.com/liblfds?tab=repositories
- brigade 12y ago
  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.
  - colanderman 12y ago
    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.

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

by brigade 12y ago

? 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 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 12y ago
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."
- jacquesm 12y ago
  For the curious, that's from here: http://www.drdobbs.com/cpp/lock-free-code-a-false-sense-of-security/210600279 http://www.drdobbs.com/cpp/lock-free-code-a-false-sense-of-s...
- mamcx 12y ago
  So if not C++, then C? Exist a good library of lock-free?
  - jacquesm 12y ago
    http://www.liblfds.org/ http://www.liblfds.org/
    - mamcx 12y ago
      Ok. Thanks. P.D: Weird github use: https://github.com/liblfds?tab=repositories https://github.com/liblfds?tab=repositories
brigade 12y ago
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.
- colanderman 12y ago
  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.