> > ODP is about HW abstraction and CPU instructions are HW features. Of > course, > > applications are free to use other libs/APIs/GCC features, but should > our > > examples do that? > > I'm not sure I agree that ODP primarily exists to abstract non-accelerator > HW, as far as I'm concerned that's really the job of the language, other > libraries, and at the end of the day the programmer. (Talk about biting > off > more than you can chew: abstracting all hardware in the system?!) > But regardless...
CPU cycle count read may be an instruction. Time counter read may an instruction. 128 bit atomic CAS may be an instruction. AES crypto may have multiple instructions. Queue enqueue may be an instruction. Memory barrier may be embedded into multiple instructions... An application that uses these instruction directly is not portable. An application that uses those through ODP API is portable. > > > "There is a single exception to this, in that the standard 128-bit > > "__atomic_compare_exchange_n" implementation on ARM is not lock-free > ..." > > > > This is the point. How about the built-in implementation on other CPU > > architectures: MIPS, PPC, Tilera, Kalray, ... etc ? Does the code build > on > > those. If it does build, does it have race conditions or dead locks due > to a > > slightly different synchronization scheme? > > A change of architecture shouldn't introduce any additional race > conditions > or deadlocks, no. If this were the case, then I agree that this example > would > be far too fragile to include. Any standards compliant implementation of > "__atomic_compare_exchange_n" will work fine - including the default one > used > by ARM platforms. As the algorithm underlying this example is supposed to > be > lock-free, though, a proper lock-free compare exchange implementation is > the > icing on the cake, showing off the properties of the algorithm in full. > Does the *example* need to show of lock-freeness? Would be enough to just show of how IP frag/reassembly is usually done on ODP? Could all assembly and ARM #ifdefs be removed if we simply don't claim the code to be lock-free ? -Petri
