two question about blog HOT 8 CLOSED

Hi!

1. Yes, this is compiler barrier. It's described in the paper at page 4:

   I added the compiler barrier asm volatile("" ::: "memory)—this is a GCC-specific
   compiler barrier—to make sure that the compiler won't move thr_p_[i].tail access
   and will access the memory location only once—to load its value to tmp_t. 
   

2. Basically I wrote the queue for x86 (including x86-64) architecture only. And the architecture in fact provides very strong memory ordering gurarntees. I particular 8.2.3.2 of Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 3: System Programming Guide specifies: "Neither Loads Nor Stores Are Reordered with Like Operations"

from blog.

@krizhanovsky,
to answer 1, If I remove the barrier, anything wrong there? Will any reorder happen? I can not understand the exactly meaning of the barrier position.
to answer 2, if i add barrier there, will it be portable to other weak memory model architecture such as ARM.
And is asm volatile("" ::: "memory) portable to any platform with gcc? or i should use __sync_synchronize instead when portable concerned.

from blog.

1. It depends on compiler. It's better to compile the code and check assembly code wether the reordering takes place.
2. I''m not familiar with ARM at all. However, I believe if you GCC intrinsics for barriers then the solution will be portable. The only reason why I didn't add the barriers for the queue to make it portable is performance: barriers are not for free and if you use a barrier when you don't need it, then you lose some performance.
3. I'd use GCC intrisics for portability rather than inline assembly.

from blog.

@krizhanovsky,
still to answer 1, now that x86/64 provides very strong memory ordering gurarntees "Neither Loads Nor Stores Are Reordered with Like Operations", is the barrier necessary at the position?

from blog.

No, because we already have strict ordering of the operations.

from blog.

@krizhanovsky, thx for your answer 😄.
Inspired by your work, I have made a lock-free ringqueue which could deal with variable-length data. Could you give me any suggestion, any is greatly appreciated.

from blog.

You're wellcome ;) And thank you for the link - I'll have a look at the project.

from blog.

😄, so I close the issue.

from blog.