Re:Common Pitfalls in Writing Lock-Free Algorithms
by raverbashing on Thursday March 28, 2013 @07:27AM
(#5454219)
Well, lots of good insights, but I don't get this:
"We currently use boost::atomic for this.
Our compiler is gcc 4.6, which currently supports std::atomic, but its implementation is much less efficient than boost’s. "
Really, never replace trust in a compiler by trust in a library.
They're getting down to all the nitty-gritty details and then saying 'a memory barrier is expensive'. It seems contradictory to me.
GCC will get better, other compilers will get better as well, but using another level of indirection (a library) is not usually a good idea.
Oh, and maybe replace the sleep by a sched_yield
And even better, don't have hundreds of threads on a single data structure, especially a constrained one like stack, that's probably the easiest way of having speed gains.
"We currently use boost::atomic for this. Our compiler is gcc 4.6, which currently supports std::atomic, but its implementation is much less efficient than boost’s. "
Really, never replace trust in a compiler by trust in a library.
They're getting down to all the nitty-gritty details and then saying 'a memory barrier is expensive'. It seems contradictory to me.
GCC will get better, other compilers will get better as well, but using another level of indirection (a library) is not usually a good idea.
Oh, and maybe replace the sleep by a sched_yield
And even better, don't have hundreds of threads on a single data structure, especially a constrained one like stack, that's probably the easiest way of having speed gains.