Re: [boost] Atomic Operations Library

From: John Maddock (john_at_[hidden])
Date: 2007-07-14 05:05:00

Matt Calabrese wrote:
> Hello, everyone. I haven't been active around here lately, but I was a
> summer of code participant
> last year working on the concurrency library (Act) which aimed to
> bring active objects, futures, lockfree datastructures, and parallel
> algorithms to Boost. For numerous reasons, after summer of code,
> my library went through some redesigns
> and I eventually came to the conclusion that the scope of the library
> was just much too big to be tackling all at once. For a little while
> I stopped work entirely, but in the past couple of months I have
> started to go back and salvage what I had done. Thanks to Dave, Jeff,
> and others for nudging me back on track.

Hey!  Welcome back :-)

> Anyway, I'm taking things a bit slower this time around and I am
> breaking everything up into smaller pieces before I pull everything
> back together. The first thing I've been working on since Boostcon
> is making a more formal and exposed atomic operations library, with a
> design influenced by the numerous C++ 0x proposals
> (In particular, it's generally most similar to Peter Dimov's
> proposal). It's still got a ways to go, but I have the general design
> out and documented, along with a little bit of implementation
> and trivial tests up and working with VC 8 and Intel 10 for windows.
> I don't recommend anyone using it yet, as its only partially
> implemented and not ported to other systems.
> Documentation is up at http://rivorus.cupofdirt.net/ and code is in
> the sandbox in soc/2006/concurrency/trunk. At this point, I'm more
> just looking to see if there is any interest in me continuing with
> this portion of the library as its own separate library, to
> potentially get it completed and up for review sooner if interest is
> there, and I'd like to hear opinions on the design (please read the
> rationale in the docs first, though, as I'm sure it will attempt to
> answer the most obvious question about the design). Also note that
> although I do not mention additional atomic
> types with overloaded operators that always use interlocked
> operations, they are planned.

Definite interest I'm sure, my only slight concern is that even your 
interlocked framework alone looks to be quite ambitious, with a lot of 
primitives.  I guess the crunch will come when you try and port to multiple 
platforms.  Looks to be headed in the right direction, based on a very quick 
look though.

John.