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.