[Gc] Re: libatomic_ops

Kevin Bowling kevin.bowling at kev009.com
Tue Feb 22 18:17:20 PST 2011

Hi Hans,

Indeed, C1x is nice and welcome.  I am, however, terrified if uptake
happens anything like C99.

If you just considered ck for the atomic ops, I ask you to dig deeper.
 ck can easily adapt or adopt to libatomic_ops or C1x as needed and as
available.  ck goes far beyond atomic ops and provides real world data
structures and other features like hazard pointers and will eventually
provide a wrapper to the patent encumbered RCU algorithm (URCU has an
exemption..).  Overall, the goal of ck transcends other related
projects I've seen and there is opportunity for us to come together.

What excites me about ck is the quality and attention paid to
portability so far, although admittedly the two targets as of now are
not indicative of success (I hope to help here).  Other concurrency
libraries I've seen are heavily married to GCC (like userspace RCU)
which is not ideal if such requirements can be abstracted properly.

libatomic_ops is a nice library because such great attention was paid
to portability and it works on virtually all architectures and most
compilers.  If this community can come together and create a good
standard concurrent library with wide portability for C, it's an
effort worth undertaking.


On Tue, Feb 22, 2011 at 1:38 PM, Boehm, Hans <hans.boehm at hp.com> wrote:
> Both C++0x and C1x standards are nearing completion.  They both contain closely related atomic operation APIs that in my (admittedly biased) opinion have been much more carefully designed than either ck or libatomic_ops.  They definitely benefited from experience with libatomic_ops and interfaces like the gcc __sync primitives.  Paul McKenney was a major contributor, so they also received input from someone familiar with the Linux kernel primitives.  If we want to make progress here, let's please work on better implementations of those in gcc etc., and then build the higher level libraries on top of those.  I consider libatomic_ops and the like a stopgap until those are widely available.
> Hans
>> -----Original Message-----
>> From: gc-bounces at linux.hpl.hp.com [mailto:gc-bounces at linux.hpl.hp.com]
>> On Behalf Of Kevin Bowling
>> Sent: Monday, February 21, 2011 12:56 PM
>> To: Ivan Maidanski
>> Cc: gc at linux.hpl.hp.com
>> Subject: [Gc] Re: libatomic_ops
>> Hi,
>> ck goes beyond atomic ops and provides memory functions, hazard
>> pointers, locks, and complete data structures.
>> Here's what ck needs:  ports to all the fine archs that libatomic_ops
>> has.  I contacted the author and would like to help do some ports.
>> What do you think about joining up so we all work together and make ck
>> the default for concurrent programming?  The C community is really
>> spread out right now with lockless structures and solid concurrency
>> primitives and we have the opportunity to fix this now.
>> Regards,
>> Kevin
>> On Mon, Feb 21, 2011 at 1:03 PM, Ivan Maidanski <ivmai at mail.ru> wrote:
>> > Hi Kevin,
>> >
>> > I'm excited too...
>> > Here's the project official site:
>> https://www.hpl.hp.com/research/linux/atomic_ops/
>> >
>> > Thanks for pointing to ck. It would be interesting to compare
>> functionalities.
>> >
>> > Regards.
>> >
>> > Sun, 20 Feb 2011 21:57:37 -0700 Kevin Bowling
>> <kevin.bowling at kev009.com>:
>> >
>> >> Hi,
>> >>
>> >> I've made libatomic_ops available via
>> >> https://github.com/kev009/libatomic_ops to ease access.  Thank you
>> for
>> >> your efforts :).
>> >>
>> >> I'm very excited about this project as well:
>>  https://repnop.org/ck/index.html
>> >>
>> >> Regards,
>> >> Kevin Bowling
>> >
>> >
>> _______________________________________________
>> Gc mailing list
>> Gc at linux.hpl.hp.com
>> https://www.hpl.hp.com/hosted/linux/mail-archives/gc/

More information about the Gc mailing list