On Feb 19, 2013, at 4:01 PM, Matthew Knepley <[email protected]> wrote:

On Tue, Feb 19, 2013 at 4:51 PM, Barry Smith <[email protected]> wrote:

On Feb 19, 2013, at 3:43 PM, Jed Brown <[email protected]> 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