[petsc-dev] concurrencykit

[Matthew Knepley]

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130219/143a6878/attachment.html>