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. 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. For a while I was considering just working on an implementation of N2324, but I personally am not a fan of its design choices and felt that this library may be better for my own personal needs. If others don't feel the same, I'll just leave this library internal to my own and continue on. As it stands, it is to have a superset of the functionality of C++0x proposals which means that it would be able to be used to implement the proposals fairly easily, and it would also be easy to implement this library if an implementation of one of the proposals is present. If anyone is interested in this project and would like to help port to other compilers and architectures, that'd be great too, but at this point I'm more just looking for design criticism. I'm going to be away from civilization this coming week on vacation until next Saturday, but I'll try to poke my head in once every day or two. Again, docs are up at : http://rivorus.cupofdirt.net/ And source is in the sandbox under soc/2006/concurrency/trunk Thanks. -- -Matt Calabrese
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.
Matt Calabrese wrote:
For a while I was considering just working on an implementation of N2324, but I personally am not a fan of its design choices and felt that this library may be better for my own personal needs. If others don't feel the same, I'll just leave this library internal to my own and continue on.
From reading the documentation for a few minutes, I already find it quite better than N2324, personally.
On 7/14/07, Matt Calabrese <rivorus@gmail.com> 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.
Welcome back :) I was missing you guys! Sorry, I am happy :D Best regards Matias
On 7/14/07, John Maddock <john@johnmaddock.co.uk> wrote:
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.
It shouldn't be much more difficult to port than the proposals. A lot of stuff is automatically generated based off of a single macro definition. Specifying a CAS definition and what size/alignment of types that are useable with CAS on your system automatically generates the entire rest of the library including the integer headers and lock-free ops on types smaller and of a different alignment as well (by taking the encapsulating word and doing CAS on that, as specified in a couple of the proposals). You can go further and provide more direct support for any other operations to override defaults, and you can even take short-cuts such as just specifying the behavior of volatile on your compiler (i.e. if volatile implies acquire loads and release stores, you just specify as such and it will generate the corresponding functions automatically based off of that). I do not yet have support for a lock-based emulated implementation. On 7/14/07, Mathias Gaunard <mathias.gaunard@etu.u-bordeaux1.fr> wrote:
From reading the documentation for a few minutes, I already find it quite better than N2324, personally.
Thanks. I've been putting a lot of time into it. On 7/14/07, Matias Capeletto <matias.capeletto@gmail.com> wrote:
Welcome back :) I was missing you guys!
Ha, thanks. The docs are looking great btw. -- -Matt Calabrese
On 7/15/07, Matt Calabrese <rivorus@gmail.com> wrote:
On 7/14/07, Matias Capeletto <matias.capeletto@gmail.com> wrote:
Welcome back :) I was missing you guys!
Ha, thanks. The docs are looking great btw.
Indeed. The stylesheet/layout of the documentation pages is very easy on the eyes. Nice work. -- Caleb Epstein
on Sun Jul 15 2007, "Matt Calabrese" <rivorus-AT-gmail.com> wrote:
It shouldn't be much more difficult to port than the proposals. A lot of stuff is automatically generated based off of a single macro definition. Specifying a CAS definition and what size/alignment of types that are useable with CAS on your system automatically generates the entire rest of the library including the integer headers and lock-free ops on types smaller and of a different alignment as well (by taking the encapsulating word and doing CAS on that, as specified in a couple of the proposals). You can go further and provide more direct support for any other operations to override defaults, and you can even take short-cuts such as just specifying the behavior of volatile on your compiler (i.e. if volatile implies acquire loads and release stores, you just specify as such and it will generate the corresponding functions automatically based off of that).
Yeah, I probably should have mentioned this earlier: Matt is really good ;-) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
participants (6)
-
Caleb Epstein -
David Abrahams -
John Maddock -
Mathias Gaunard -
Matias Capeletto -
Matt Calabrese