On Feb 19, 2013, at 4:01 PM, Matthew Knepley <knepley at gmail.com> wrote:
> On Tue, Feb 19, 2013 at 4:51 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: > > 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. > > I agree. Useless wrappers (TaoVec, TrilinosCommStuff) just clutter code and > do not expand functionality. But maybe next week MPI won't be used any more and we have to be prepared for that day. Barry > > What is your opinion of the longevity of support? Will we end up supporting > this library? > > Matt > > > Barry > > > > > > -- > What most experimenters take for granted before they begin their experiments > is infinitely more interesting than any results to which their experiments > lead. > -- Norbert Wiener
