On Feb 19, 2013, at 3:43 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> I've started adding support for using this library for memory primitives and > some basic lock-free data structures. > > http://concurrencykit.org/ > > Of course when threads are not used, we need some replacement. All the memory > barriers and assignments become trivial and locks disappear so the > no-threading variant is trivial to implement. My question now is whether to > call ck_* functions directly from PETSc source or to always wrap them in > Petsc* namespaced macros and inline functions. > > I would normally always use a Petsc namespace for this kind of thing, but > this library has convenient man pages and is, I think, the best thing out > there for implementing these primitives. Wrapping everything in a Petsc* > namespace would thus make it less direct to get down to the actual semantics > (or a man page). Thus I have half a mind to treat it like MPI and just > provide non-threaded implementations in petscck.h when > !defined(PETSC_HAVE_CONCURRENCYKIT). Is this a bad idea? I can live with it. You, of course, are providing a --download-ck before writing a single line of code that uses ck. Barry
