ck_backoff: add missing compiler barrier to busy loop body. (c.f. #23) about ck HOT 3 CLOSED

@pkhuong, just to make sure I understand, in which situations will the busy-wait counter be compiled away? The variable is volatile and there are side effects, and as far as I know, there is no room in the C specification to allow for this to be compiled away. This was verified across various versions of Sun, GCC, clang and ICC (haven't checked against GCC trunk).

Back when this was developed, there was no explicit compiler barrier. Now that there is explicit compiler barrier, we should be using ck_pr_barrier for sure. volatile should not be used for busy-wait counter when there is an alternative. We want a plain barrier in this case as ck_pr_stall will either lead to unnecessary jitter (SMT Power) or unnecessary load-load ordering.

from ck.

Agreed that the compiler barrier is clearly better. I don't want to dive in the spec, but I'm pretty sure that an extremely aggressive compiler could notice that "i" doesn't escape the scope of the for loop and, in effect, remove the volatile qualifier.

On Jan 26, 2015, at 18:36, Samy Al Bahra [email protected] wrote:

@pkhuong, just to make sure I understand, in which situations will the busy-wait counter be compiled away? The variable is volatile and there are side effects, and as far as I know, there is no room in the C specification to allow for this to be compiled away. This was verified across various versions of Sun, GCC, clang and ICC (haven't checked against GCC trunk).

Back when this was developed, there was no explicit compiler barrier. Now that there is explicit compiler barrier, we should be using ck_pr_barrier for sure. volatile should not be used for busy-wait counter when there is an alternative. We want a plain barrier in this case as ck_pr_stall will either lead to unnecessary jitter (SMT Power) or unnecessary load-load ordering.

—
Reply to this email directly or view it on GitHub.

from ck.

The loop predicate requires volatile side effect which is not constant and requires volatile-volatile ordering, so I thought the language was clear in this matter. We have been bitten by code movement issues in the past, but that was in the presence of compiler barriers and involved interaction of volatile and non-volatile types.

Neither the literature (at least, that I know of) or the specification would agree with such an optimization, and I haven't heard of a compiler optimizing this pattern away (ignoring compiler bugs). If you happen across this for some reason, would love to hear what you find!

In the mean time, ck_backoff is replaced to use ck_pr_barrier which does get rid of load / store operations at least in silly benchmarks.

from ck.