lockfree_rb_q.cc volatile about blog HOT 6 CLOSED

Hi,

thanks for your interest to the lock-free queue and the article. Actually, the queue in the repository is developed further than the original implementation in the article. In particular, since volatile is considered harmful and bad practice the queue in the repository uses compiler barriers where necessary instead of defining the queue properties as volatile.

builtin_expect is just a compiler hint how to place the code, e.g. in the code at the below

if (builtin_expect(cond, 0)) {
     A;
} else {
    B;
}

while A expression is placed before B, compiler moves it after more likely B. This is bit different optimization than volatile specifier.

from blog.

Thanks for your response. I'm looking at the code from the article and the n consumer m producer lock free implementation and it seems like they are both the same. Could you point me to where the differences are ? I apologize since it is not immediately obvious where the differences are. IT appears that the code in the repo simply discards volatile and it still works.

from blog.

To be more clear, my question comes from the while loop in the push and pop methods from lines 250 and 297. what prevents the compiler from generating code that loads tail and last_head_ into registers and use them in the while loop "while (_builtin_expect(thr_pos().tail >= last_head, 0))," ?

from blog.

The exact change which you are looking for is 307a6e9 : initially the queue was developed with too strong memory ordering requirements while x86-64 already provides strong enough guarantees. So the commit references Intel documentation about the memory ordering guarantees. The commit removes volatile and introduces memory and compiler barriers. Please follow the latest commits (git log lockfree_rb_q.cc) - some of the barriers also were optimized out.

what prevents the compiler from generating code that loads tail and last_head_ into registers and use them in the while loop "while (_builtin_expect(thr_pos().tail >= last_head, 0))," ?

thr_pos().tail is our thread local variable, nobody changes it but us, so we're completely OK with letting the compiler cache it. Meantime latst_head_ is calculated inside the loop body, so compiler isn't allowed to ignore the variable update in the loop and just cache some old value.

from blog.

@krizhanovsky Thanks! Makes perfect sense now! Appreciate your prompt responses.

from blog.

Nice to read that my answers helped you!

from blog.