On Sun, 30 Apr 2006 18:20:46 -0400, Matt Calabrese wrote

I'd be proposing the project as a student. I will be sending in a formal application through SoC later this week, though I thought I'd run the idea by the mailing list first to see if there is any interest.

Excellent -- After my brief look at your docs, it looks very interesting to me -- so I would encourage you to go forward :-) Jeff

Thanks, I will be looking into the interfaces provided. For clarity, atomic types in my library are currently all internally emulated with a thread-safe active type implementation using an immediate act model which automatically forces a wait prior to returning (see my linked doc in the original post for what active types and act model are specifically with respect to the library). Clearly this is not very efficient particularly for built-in types, but it is the simplest implementation to get up and running in a fairly portable manner which accounts for user-defined types with a well-defined active interface. That being said, the main goal of atomic types in my library (which is only a small part of the library) is to provide an easy way to create thread-safe user-defined types of any complexity, which serialize all operations upon them and are accessed through any interface provided by means described in the documentation. This allows programmers to create complex types and easily have a way to safely use instances of them by multiple threads at the same time and have the operations not return until the call completes as though all operations were atomic. Of course, for built-in types specifically, more efficient techniques can be used internally, but that is not of primary concern at this point. Really, the focus of the library is for the creation of parallel loops and active functions and active types, with atomic types provided as a simple adapter for active types. -- -Matt Calabrese

On 5/1/06, Beman Dawes <bdawes@acm.org> wrote:

If you haven't done so already, be sure to look at Ion Gaztañaga's implementation in the Boost Vault of Kevlin Henney's N1883 futures design. It is under active development.

--Beman

I'm aware of the futures in active development, though my library is unique with respect to other active function and active object implementations in that it avoids the concept of futures almost entirely, or rather, merges the concept of futures with the concept of a running asynchronous function (represented by an action in the library) and the concept of active objects as conceptual return types of asynchronous calls rather than "future" values. By that I mean in order to create an active function call, you merely instantiate an action, passing the function object and arguments to the constructor. Access to the return value is granted through the action indirectly with * and -> but the interface of the value is actually the associated active qualified form of the return type and so operations performed on it are all serialized and do not imply a wait, even for complex user-defined types. Basically, instead of futures, the return type is thought of as an active type whose thread is not created until operations on it are queued. This provides a superset of the functionality provided by futures as you can still get the "inactive" form of the return type and force a wait for any type, however such a loss of concurrency is not necessary for any type which has a well-defined active interface, including complex user-defined types. -- -Matt Calabrese