> -----Original Message----- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Chao CH Zhu > Sent: Thursday, October 16, 2014 4:14 AM > To: Ananyev, Konstantin > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH 02/12] Add atomic operations for IBM Power > architecture > > Konstantin, > > In my understanding, compiler barrier is a kind of software barrier which > prevents the compiler from moving memory accesses across the barrier. This > should be architecture-independent. And the "sync" instruction is a > hardware barrier which depends on PowerPC architecture. So I think the > compiler barrier should be the same on x86 and PowerPC. Any comments? > Please correct me if I was wrong. > I would agree with that assessment, as far as it goes, in that a compiler barrier is going to be the same on both architectures. However, we also need to start thinking about actual use cases - how to we specify the barriers in a piece of code where we need a full memory barrier on PPC and only a compiler barrier on IA? My suggestion would be to do first as you propose and have proper primitives for the different barrier types defined correctly for each platform - with the compiler barrier being, presumably, common across each one. Then, as a second step, we probably need to look at defining "logical" barrier types (for want of a better term) that can then be used in the code and which would be different across platforms.
Does this make sense to do this way? Is it the best solution? Do we want to define the basic primitives or are we only ever likely to need the logical barrier types? /Bruce
