From 3ca7072c146b62dd800e51ed5b3e49e7af5adeed Mon Sep 17 00:00:00 2001 From: Samy Al Bahra Date: Sat, 25 May 2013 14:08:30 -0400 Subject: [PATCH] ck_pr: Implicit compiler barrier ck_pr_fence. I accidentally removed ck_pr_fence implicit compiler barrier semantics in re-structure of ck_pr_fence. This does affect the correctness of any data structures in ck_pr_fence or the correctness of consumers of ck_pr operations where ck_pr serves as linearization points. The reason it does not affect any CK data structures is that explicit compiler barriers (whether they are store/load operations or atomic ready-modify-write operations) always serve as linearization points. However, if consumers are doing tricky things like using these barriers to serialize aliased locations for correctness, then it is possible for compiler re-ordering to bite them in the ass. --- include/ck_pr.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/ck_pr.h b/include/ck_pr.h index 2d49f62..b3e8094 100644 --- a/include/ck_pr.h +++ b/include/ck_pr.h @@ -57,11 +57,13 @@ ck_pr_fence_##T(void) \ { \ ck_pr_fence_strict_##T(); \ + return; \ } #define CK_PR_FENCE_NOOP(T) \ CK_CC_INLINE static void \ ck_pr_fence_##T(void) \ { \ + ck_pr_barrier(); \ return; \ }