The LGPL license raises red flags with me as Cray considers LGPL to be a non-permissive license. It could slow the process of getting this approved through BlackDuck. It has to go through full approval and that can take months these days as the pipeline is quite full. I already have one item that has not been formally approved yet (libunwind) and I suspect this library would take longer.
Just a thought. TMacD On Mon, 28 Nov 2016, Michael Ferguson wrote: > Hi - > > I've been wondering if it might make sense to use liburcu > with Chapel. Does anybody have experience with this library? > The website describes the library like this: > >> liburcu is a LGPLv2.1 userspace RCU (read-copy-update) >> library. This data synchronization library provides >> read-side access which scales linearly with the number >> of cores. > > > See Resources below if you want to read up on it. > > In particular I'm interested in applying this library to > make --cache-remote have 1 cache per locale. (The current > strategy is 1-cache-per-pthread but that runs into problems > if the tasking layer wants to do work stealing and also > limits the usefulness of the cache since task creation > causes flush/invalidate). > > Additionally, I can see a few other ways in which we might be > able to use RCU to reduce contention: > - domain memory management (reference listing) > (this is done with locks right now) > - adding and freeing privatized objects > (right now, arrays mapping private id -> object are leaked) > > Lastly, it seems potentially promising to try to extend > the basic RCU operations to multiple locales. I believe that > is not only possible but also not to hard. However I am uncertain > of the performance implications. (It seems to me that it might > have reasonably good performance if we are able to defer operations > after a synchronize_rcu - typically freeing an object - to > some kind of work queue - as with call_rcu in liburcu. The > deferred operations would need to be run only after all cores on > all locales ran a memory barrier. One easy strategy here would be > to periodically - say every 10 seconds - run the memory barriers > on all locales and then run the deferred operations. I'm sure > that there are ways to make use of local consistency - such > as tracking a grace period sequence number...). > > > Resources: > > Userspace RCU website, source code > http://liburcu.org/ > https://github.com/urcu/userspace-rcu > > > Introduction to RCU Concepts (slides) > https://www.efficios.com/pub/linuxcon-europe-2013/ > mdesnoyers-userspace-rcu-tutorial-linuxcon-2013.pdf > > > What is RCU, Fundamentally? LWN article > > https://lwn.net/Articles/262464/ > > > sys_membarrier LWN article > https://lwn.net/Articles/369567/ > (sys_membarrier is a Linux system call added to support liburcu) > > > Thanks for any information, > > -michael > > ------------------------------------------------------------------------------ > _______________________________________________ > Chapel-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/chapel-developers > ------------------------------------------------------------------------------ _______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
