[futures] composite or

[Sohail Somani]

Hi,

I was looking at the futures implementation in the boost vault. It looks
very promising, I must say. One of the open issues however is thread
cancellation which I imagine will be important in the case of the "or"
futures group.

Has there been any progress on this front? One of the coolest things
about boost libraries has been the gradual improvement of legacy C/C++
code by non-invasive means. I can't imagine solving this problem without
invasive means (or traditionally undesirable means, i.e. something like
thread->die()). I'm not saying that its non-invasive or nothing, but
there are people smarter than me working on this problem!

Thanks in advance,

Sohail
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[braddock]

I just started looking at the boost::futures zip file in the vault as
well. I'd really like to use it for a current project if it is near
maturity.

Can I use it in conjunction with my own thread pool or with an active
object?

For example, I'd want something like:
int f();
future<int> val = myThreadPool.queue<int>(f);
val.ready()
val.cancel()
etc..

The documentation is incomplete except for the simple case, which
appears to spawn a new thread for every new future?

The ability to use a future with the asio::io_service in particular would
be quite powerful.

Thanks,
Braddock Gaskill
Dockside Vision Inc

On Tue, 20 Feb 2007 12:11:56 -0800, Sohail Somani wrote:

> I was looking at the futures implementation in the boost vault. It looks
> very promising, I must say. One of the open issues however is thread
> cancellation which I imagine will be important in the case of the "or"
> futures group.
>
> Has there been any progress on this front? One of the coolest things
> about boost libraries has been the gradual improvement of legacy C/C++
> code by non-invasive means. I can't imagine solving this problem without
> invasive means (or traditionally undesirable means, i.e. something like
> thread->die()). I'm not saying that its non-invasive or nothing, but
> there are people smarter than me working on this problem!
>
> Thanks in advance,
>
> Sohail
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Hartmut Kaiser]

 
Braddock Gaskill wrote:

> I just started looking at the boost::futures zip file in the
> vault as well. I'd really like to use it for a current
> project if it is near maturity.

It's far from mature. Just a first (but functional) sketch.

> Can I use it in conjunction with my own thread pool or with
> an active object?

If you write the thread pool or active object support, certainly. The
library as is doesn't know anything about thread pools or active objects. It
just spawns a new thread for every future.

> For example, I'd want something like:
> int f();
> future<int> val = myThreadPool.queue<int>(f);
> val.ready()
> val.cancel()
> etc..

val.cancel() isn't supported at all, mainly because Boost.Thread doesn't
support cancel.

> The documentation is incomplete except for the simple case,
> which appears to spawn a new thread for every new future?

Yes.

> The ability to use a future with the asio::io_service in
> particular would be quite powerful.

Agreed. And I'm happy to assist, if needed.

Regards Hartmut

> Thanks,
> Braddock Gaskill
> Dockside Vision Inc
>
> On Tue, 20 Feb 2007 12:11:56 -0800, Sohail Somani wrote:
> > I was looking at the futures implementation in the boost vault. It
> > looks very promising, I must say. One of the open issues however is
> > thread cancellation which I imagine will be important in
> the case of the "or"
> > futures group.
> >
> > Has there been any progress on this front? One of the
> coolest things
> > about boost libraries has been the gradual improvement of
> legacy C/C++
> > code by non-invasive means. I can't imagine solving this problem
> > without invasive means (or traditionally undesirable means, i.e.
> > something like
> > thread->die()). I'm not saying that its non-invasive or nothing, but
> > there are people smarter than me working on this problem!
> >
> > Thanks in advance,
> >
> > Sohail
> > _______________________________________________
> > Unsubscribe & other changes:
> > http://lists.boost.org/mailman/listinfo.cgi/boost
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[braddock]

On Fri, 09 Mar 2007 13:57:52 -0600, Hartmut Kaiser wrote:

>> Can I use it in conjunction with my own thread pool or with
>> an active object?
>
> If you write the thread pool or active object support, certainly. The
> library as is doesn't know anything about thread pools or active objects. It
> just spawns a new thread for every future.

I noticed that none of the "future" C++ standardization proposals by
Hinnant and Dimov, as well as Sutter's Concur implicitly create a new
thread upon future construction like your simple_future implementation.
As far as I can tell, their future classes are very simple and almost
completely agnostic to the scheduling, threading, etc particulars.

ie, the Hinnant proposal at
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2094.html#futures
would do the following if a new thread was needed:
std::future<int> f1 = std::launch_in_thread(f);

but more likely in the real world since thread creation is expensive:
std::future<int> f1 = std::launch_in_pool(f);

In the meanwhile, Sutter is on an Active Object kick:
future<int> f1 = myActiveProxy.f()

I noticed that your implementation of simple_future takes a considerably
different tack, where future_base is derived and typed, and the derived
future sub-class itself has knowledge of how to launch the thread with the
functions.

Glancing through the code, this seems to add considerable complexity and
dependencies to class future, and encourages users to sub-type class
future, a la simple_future.  

Is there any reason task creation, scheduling, and threading can't be
entirely disentangled from the future concept?
 
> val.cancel() isn't supported at all, mainly because Boost.Thread doesn't
> support cancel.

Thread lifetime won't necessary (usually?) be linked to asynchronous
function call lifetime.  Sutter makes use of a future::cancel(), and Dimov
notes "Once a thread layer and a cancelation layer are settled upon,
future would need to offer support for canceling the active asynchronous
call when the caller is no longer interested in it;"

Maybe this could be handled with an optional "cancel" function passed to
the future constructor, like the way a custom destructor can be passed to
a shared_ptr.  If cancel() is a no-op for some scenarios, it could either
throw or be ignored.

I have a serious need for this functionality, so I'm willing to put in a
bit of effort to work up some solution.

Thanks,
Braddock Gaskill
Dockside Vision Inc

>
>> The documentation is incomplete except for the simple case, which
>> appears to spawn a new thread for every new future?
>
> Yes.
>
>> The ability to use a future with the asio::io_service in particular
>> would be quite powerful.
>
> Agreed. And I'm happy to assist, if needed.
>
> Regards Hartmut
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Peter Dimov]

Braddock Gaskill wrote:

> I noticed that none of the "future" C++ standardization proposals by
> Hinnant and Dimov, as well as Sutter's Concur implicitly create a new
> thread upon future construction like your simple_future
> implementation.
> As far as I can tell, their future classes are very simple and almost
> completely agnostic to the scheduling, threading, etc particulars.

Indeed, the intent has been for futures to support arbitrary asynchronous
task execution, not just the simple thread per task model. One could imagine
using futures over an interprocess protocol or TCP/IP.

My current proposal for std::future<R> is available at

http://www.pdimov.com/cpp/N2185.html

and will be part of the pre-meeting mailing. We'll see how it fares.

As an aside, does anyone have a success story about active objects? I can't
seem to grasp their significance; in particular, how are they supposed to
scale to many cores/HW threads if every access is implicitly serialized?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Sohail Somani]

> -----Original Message-----
> From: boost-bounces@...
> [mailto:boost-bounces@...] On Behalf Of Braddock Gaskill

> I noticed that none of the "future" C++ standardization proposals by
> Hinnant and Dimov, as well as Sutter's Concur implicitly create a new
> thread upon future construction like your simple_future
> implementation.
> As far as I can tell, their future classes are very simple and almost
> completely agnostic to the scheduling, threading, etc particulars.

You are right. The idea is to be able to scale to whatever the node can
handle.

So 100 futures on a single processor node would probably not execute in
100 threads(!)

> Is there any reason task creation, scheduling, and threading can't be
> entirely disentangled from the future concept?

Maybe not entirely, but at some point the future would probably tell
some "future scheduler" to schedule the future. I think this is as far
as the futures concept should know about scheduling or threads (i.e.,
not much!)

> > val.cancel() isn't supported at all, mainly because
> Boost.Thread doesn't
> > support cancel.
>
> Thread lifetime won't necessary (usually?) be linked to asynchronous
> function call lifetime.  Sutter makes use of a
> future::cancel(), and Dimov
> notes "Once a thread layer and a cancelation layer are settled upon,
> future would need to offer support for canceling the active
> asynchronous
> call when the caller is no longer interested in it;"

I think the real power of futures is in future groups, which would
require thread cancellation. Seems like you would have to modify the
worker code to either tell the API that you are cancellable or to check
if you've been asked to be cancelled. I think an API would be ideal
which is probably what Dimov is getting at.

Sohail

PS: IMVHO active objects are iffy, I like futures.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Sohail Somani]

> -----Original Message-----
> From: boost-bounces@...
> [mailto:boost-bounces@...] On Behalf Of Peter Dimov

> Indeed, the intent has been for futures to support arbitrary
> asynchronous
> task execution, not just the simple thread per task model.
> One could imagine
> using futures over an interprocess protocol or TCP/IP.
>
> My current proposal for std::future<R> is available at
>
> http://www.pdimov.com/cpp/N2185.html

May I ask why you saw it necessary to have std::fork in that
incarnation? Won't you /always/ do the same thing?

I'm not sure why we couldn't have it be implied that construction of a
future implies "fork".

Thanks,

Sohail
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Peter Dimov]

Sohail Somani wrote:

>> Indeed, the intent has been for futures to support arbitrary
>> asynchronous
>> task execution, not just the simple thread per task model.
>> One could imagine
>> using futures over an interprocess protocol or TCP/IP.
>>
>> My current proposal for std::future<R> is available at
>>
>> http://www.pdimov.com/cpp/N2185.html
>
> May I ask why you saw it necessary to have std::fork in that
> incarnation?

Lawrence Crowl has made an excellent point that it's important for us to
support the most common use case in a simple way, even if this means that we
have to sacrifice generality to do so. Hence std::fork and the simple
examples.

> Won't you /always/ do the same thing?
>
> I'm not sure why we couldn't have it be implied that construction of a
> future implies "fork".

I didn't want to sacrifice the generality we already did have. :-) You can
still make your non-blocking API (an active object, a C++ RPC interface)
return a future. std::fork is merely a convenient way to use an efficient
system-provided thread pool. Nothing stops you from writing your own 'fork'
that doesn't, as shown in N2096.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Sohail Somani]

> -----Original Message-----
> From: boost-bounces@...
> [mailto:boost-bounces@...] On Behalf Of Peter Dimov

> > I'm not sure why we couldn't have it be implied that
> construction of a
> > future implies "fork".
>
> I didn't want to sacrifice the generality we already did
> have. :-) You can
> still make your non-blocking API (an active object, a C++ RPC
> interface)
> return a future. std::fork is merely a convenient way to use
> an efficient
> system-provided thread pool. Nothing stops you from writing
> your own 'fork'
> that doesn't, as shown in N2096.

I think I get it. I suppose I was thinking along the lines of (default)
allocators. I've implemented a futures-like concept that went kind of
along those lines so I guess I am a bit biased :)

Thanks,

Sohail
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Jeff Garland]

Peter Dimov wrote:

> Braddock Gaskill wrote:
>
>> I noticed that none of the "future" C++ standardization proposals by
>> Hinnant and Dimov, as well as Sutter's Concur implicitly create a new
>> thread upon future construction like your simple_future
>> implementation.
>> As far as I can tell, their future classes are very simple and almost
>> completely agnostic to the scheduling, threading, etc particulars.
>
> Indeed, the intent has been for futures to support arbitrary asynchronous
> task execution, not just the simple thread per task model. One could imagine
> using futures over an interprocess protocol or TCP/IP.
>
> My current proposal for std::future<R> is available at
>
> http://www.pdimov.com/cpp/N2185.html
>
> and will be part of the pre-meeting mailing. We'll see how it fares.
>
> As an aside, does anyone have a success story about active objects? I can't
> seem to grasp their significance; in particular, how are they supposed to
> scale to many cores/HW threads if every access is implicitly serialized?

Sure, they're useful.  Couple ways they can scale.  You might have a large
number of totally independent active objects running at any giving time.  For
example, imagine and 'endpoint' handler for a telephone calls -- it's a
complex state machine that's executes a bunch of commands as new events
arrive.  If you handle lots of calls and you map 1 per thread then you are
effectively scaling to many cores by having lots of active objects.  Probably
a better design is to have a pool of threads wake up the AO when a new event
arrives, b/c at any moment most of the objects are idle and there's no point
in tying up a thread.

Totally different approach is for a single active object to have a pool of
threads to dispatch execution of long running tasks within the AO.  In this
design even though the start of tasks is serialized the end might not be.  The
AO needs to be essentially stateless for this approach to work.

HTH,

Jeff

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Hartmut Kaiser]

 
Braddock Gaskill wrote:

In short, I completely agree with your points. But remember, the futures
implementation in the vault has been written long before any of these
proposals have been published, so it's just an useful experiment, even if
not with optimal results.

I'm personally very interested in the futures concept as well, so please
count me in when it comes to any new implementations. We should try to get
it as close as possible to a future standard, though.

Regards Hartmut

> I noticed that none of the "future" C++ standardization
> proposals by Hinnant and Dimov, as well as Sutter's Concur
> implicitly create a new thread upon future construction like
> your simple_future implementation.
> As far as I can tell, their future classes are very simple
> and almost completely agnostic to the scheduling, threading,
> etc particulars.
>
> ie, the Hinnant proposal at
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2094.

html#futures

> would do the following if a new thread was needed:
> std::future<int> f1 = std::launch_in_thread(f);
>
> but more likely in the real world since thread creation is expensive:
> std::future<int> f1 = std::launch_in_pool(f);
>
> In the meanwhile, Sutter is on an Active Object kick:
> future<int> f1 = myActiveProxy.f()
>
> I noticed that your implementation of simple_future takes a
> considerably different tack, where future_base is derived and
> typed, and the derived future sub-class itself has knowledge
> of how to launch the thread with the functions.
>
> Glancing through the code, this seems to add considerable
> complexity and dependencies to class future, and encourages
> users to sub-type class future, a la simple_future.  
>
> Is there any reason task creation, scheduling, and threading
> can't be entirely disentangled from the future concept?
>  
> > val.cancel() isn't supported at all, mainly because Boost.Thread
> > doesn't support cancel.
>
> Thread lifetime won't necessary (usually?) be linked to
> asynchronous function call lifetime.  Sutter makes use of a
> future::cancel(), and Dimov notes "Once a thread layer and a
> cancelation layer are settled upon, future would need to
> offer support for canceling the active asynchronous call when
> the caller is no longer interested in it;"
>
> Maybe this could be handled with an optional "cancel"
> function passed to the future constructor, like the way a
> custom destructor can be passed to a shared_ptr.  If cancel()
> is a no-op for some scenarios, it could either throw or be ignored.
>
> I have a serious need for this functionality, so I'm willing
> to put in a bit of effort to work up some solution.
>
> Thanks,
> Braddock Gaskill
> Dockside Vision Inc
>
>
> >
> >> The documentation is incomplete except for the simple case, which
> >> appears to spawn a new thread for every new future?
> >
> > Yes.
> >
> >> The ability to use a future with the asio::io_service in
> particular
> >> would be quite powerful.
> >
> > Agreed. And I'm happy to assist, if needed.
> >
> > Regards Hartmut
> >
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Peter Dimov]

Jeff Garland wrote:
> Peter Dimov wrote:

>> As an aside, does anyone have a success story about active objects?
>> I can't seem to grasp their significance; in particular, how are
>> they supposed to scale to many cores/HW threads if every access is
>> implicitly serialized?
>
> Sure, they're useful.  Couple ways they can scale.  You might have a
> large number of totally independent active objects running at any
> giving time.

I figured that many active objects would be able to scale, I just wasn't
able to come up with a realistic use case.

> For example, imagine and 'endpoint' handler for a
> telephone calls -- it's a complex state machine that's executes a
> bunch of commands as new events arrive.  If you handle lots of calls
> and you map 1 per thread then you are effectively scaling to many
> cores by having lots of active objects.

I'm afraid that I still don't get it. What does an active object represent
in this scheme, and who is invoking its methods and waiting for its results?

[...]

> Totally different approach is for a single active object to have a
> pool of threads to dispatch execution of long running tasks within
> the AO.  In this design even though the start of tasks is serialized
> the end might not be.  The AO needs to be essentially stateless for
> this approach to work.

A stateless object is not an interesting case since it's essentially a bunch
of functions inside a namespace. One could simply use future+fork to spawn
the calls. The classic active object idiom, as I understand it, deals with
the shared state problem by implicitly serializing the method calls via a
message queue, so that concurrent access to the state is eliminated. It's
possible that the term has grown since then. :-)

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Jeff Garland]

Peter Dimov wrote:

>> For example, imagine and 'endpoint' handler for a
>> telephone calls -- it's a complex state machine that's executes a
>> bunch of commands as new events arrive.  If you handle lots of calls
>> and you map 1 per thread then you are effectively scaling to many
>> cores by having lots of active objects.
>
> I'm afraid that I still don't get it. What does an active object represent
> in this scheme, and who is invoking its methods and waiting for its results?

Well, for sake of discussion, lets say it represents the 'call' between one or
more telephones.  So when someone starts to place a call a new active
object/thread is created on a server to process the call.  Depending on the
kind of phone system it will do stuff like collect digits, execute timeouts,
see of the other end is available, keep track of billing, setup network
connections, handle disconnects from phones, etc.  Each method on the object
is inherently asynchronous and often depends on getting information from a
remote servers.  This kind of object obviously would live in a larger
distributed system, but at the server level the strategy is to code the 'call
object' as an active object that responds to events.  In the real world it
might be a tad more complicated -- like you might have active objects for
devices as well -- but hopefully that explains the basic idea.

> [...]
>
>> Totally different approach is for a single active object to have a
>> pool of threads to dispatch execution of long running tasks within
>> the AO.  In this design even though the start of tasks is serialized
>> the end might not be.  The AO needs to be essentially stateless for
>> this approach to work.
>
> A stateless object is not an interesting case since it's essentially a bunch
> of functions inside a namespace. One could simply use future+fork to spawn
> the calls.

Sure, but the point of the active object is that the concurrency approach is a
detail is hidden behind the interface of the object.

> The classic active object idiom, as I understand it, deals with
> the shared state problem by implicitly serializing the method calls via a
> message queue, so that concurrent access to the state is eliminated. It's
> possible that the term has grown since then. :-)

Ok, I was a bit sloppy...the object can have state, it's just that the methods
that are spawned to execute in a thread pool must be independent of any state
changes the other makes.  In the case of the 'call object' the order things
arrive impacts the results.  Some other kinds of objects (eg: the call object)
that isn't true.

If you haven't already you might want to have a look at this paper:

http://citeseer.ist.psu.edu/lavender96active.html

Jeff
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Peter Dimov]

Jeff Garland wrote:

> Sure, but the point of the active object is that the concurrency
> approach is a detail is hidden behind the interface of the object.

It's clear that you're using a broader definition of "active object" - any
object that provides an asynchronous interface. I'm not, I'm interested in
the specific case of:

>> The classic active object idiom, as I understand it, deals with
>> the shared state problem by implicitly serializing the method calls
>> via a message queue, so that concurrent access to the state is
>> eliminated.

The significance of the classic definition is that you can take an existing
single threaded object and turn it into an active object _automatically_. In
Concur, for example, the language can do that for you; the various proposals
for a Boost implementation do something similar.

If you use the broader definition, AO becomes a pattern, and you can't
implement it in either the language or the library.

> If you haven't already you might want to have a look at this paper:
>
> http://citeseer.ist.psu.edu/lavender96active.html

I will, thank you.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[braddock]

On Sat, 10 Mar 2007 01:54:57 +0200, Peter Dimov wrote:

> Braddock Gaskill wrote:
> My current proposal for std::future<R> is available at
> http://www.pdimov.com/cpp/N2185.html
> and will be part of the pre-meeting mailing. We'll see how it fares.

Thanks Peter,

I coded up a quick straight-forward implementation of your proposal.  I'll make
it available as soon as I test it a little.  Maybe it can be grafted into the
vault implementation to provide composites, etc.

I have a few questions/comments:

1) void set_exception( exception_ptr p);

This is tricky.  I don't really want to pass and throw to the caller an
exception pointer because responsibility for deleting the exception pointer
will be very difficult to get right.  Imagine the case where two objects each
hold references to the same future, and so the exception gets re-thrown twice
as they both try to access the value.  Which one delete's the exception
pointer?

Should the future handle deletion responsibilty when the last future<>
reference is gone?

What type should the pointer be?  We can't assume that all exceptions are even
derived from std::exception.

Passing by value is a no-go because of slicing issues due to the unknown exact
type of the exception (even the calling code probably won't know).

2) Are multiple calls to set_value() permitted for a single future object?

Your prior proposal (N2096) returned the value by reference, implying that
multiple set_value() calls could not be allowed.  This proposal returns by
value, so multiple calls are at least possible.

IMHO, it should not be allowed.  The future object does not have any way to
ensure that the "consumer" gets every successive value the "producer" might
set.  Too confusing.

3) What should 'timespec' be?  I'm using boost::threads::xtime

4) set_cancel_handle(thread::handle )

This thread handle seems to assume that future<> is being used with a
thread-per-invocation, and does not appear to provide a mechanism for canceling
a queued invocaction, which is necessary for at least my application.  I'd need
a generic "callback-on-cancel()".

5) join()/try_join() vs wait()/ready()

As far as I can tell, you renamed the wait() and ready() to join() and
try_join().  In my opinion, these names are far less clear, and again my
anti-thread-per-invocation bias doesn't like the implied thread semantics.

In particular, try_join() makes little sense in a polling context.  A naive
programmer would be more likely to want to use has_value() instead, which would
be WRONG if the method throws.

while (!has_value()) //infinite loop if has_exception
  do something;

6) operator R() const;

My opinion here, but if I understand this then the semantics of this are far
too subtle.  

future<int> x = std::fork(myfunc);
//200 lines later
z = x + y; // this blocks or throws, mystifying young programmers everywhere

I liked your prior proposal N2096 which would have:
z = x() + y; // x is not your grandfather's variable

Also, what is the meaning of:
mysubroutine(x) // Does this block or throw, or just use a future argument?

What is the meaning if mysubroutine is declared:
template<T> mysubroutine(T a);

Thanks,
Braddock Gaskill
Dockside Vision Inc



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Peter Dimov]

Braddock Gaskill wrote:

> On Sat, 10 Mar 2007 01:54:57 +0200, Peter Dimov wrote:
>
>> Braddock Gaskill wrote:
>> My current proposal for std::future<R> is available at
>> http://www.pdimov.com/cpp/N2185.html
>> and will be part of the pre-meeting mailing. We'll see how it fares.
>
> Thanks Peter,
>
> I coded up a quick straight-forward implementation of your proposal.
> I'll make it available as soon as I test it a little.  Maybe it can
> be grafted into the vault implementation to provide composites, etc.

I have one, too; look at the 'Implementability' section for the links.

> I have a few questions/comments:
>
> 1) void set_exception( exception_ptr p);
>
> This is tricky.  I don't really want to pass and throw to the caller
> an exception pointer because responsibility for deleting the
> exception pointer will be very difficult to get right.  Imagine the
> case where two objects each hold references to the same future, and
> so the exception gets re-thrown twice as they both try to access the
> value.  Which one delete's the exception pointer?
>
> Should the future handle deletion responsibilty when the last future<>
> reference is gone?
>
> What type should the pointer be?  We can't assume that all exceptions
> are even derived from std::exception.

exception_ptr is described in

http://www.pdimov.com/cpp/N2179.html

and is typically a reference-counted smart pointer. If the proposal for
language support doesn't pass, we'll have to live with something along the
lines of

http://www.pdimov.com/cpp/N2179/exception_ptr.hpp
http://www.pdimov.com/cpp/N2179/exception_ptr.cpp

as linked from N2185.

> 2) Are multiple calls to set_value() permitted for a single future
> object?

Allowed, with the second and subsequent calls ignored.

> 3) What should 'timespec' be?  I'm using boost::threads::xtime

'struct timespec' as described in POSIX <time.h>, basically

struct timespec
{
    time_t tv_sec;
    long tv_nsec;
};

> 4) set_cancel_handle(thread::handle )
>
> This thread handle seems to assume that future<> is being used with a
> thread-per-invocation, and does not appear to provide a mechanism for
> canceling a queued invocaction, which is necessary for at least my
> application.  I'd need a generic "callback-on-cancel()".

Yes, you are right that set_cancel_handle is limited to canceling threads. I
was short on time since the pre-mailing deadline was yesterday so I went
with what I already had implemented. set_cancel_callback would've been more
general, but could open the door to deadlocks. I'll probably revise the
paper for the meeting to generalize the cancel support to accept an
arbitrary callback if I'm satisfied with the semantics of such a design.

> 5) join()/try_join() vs wait()/ready()
>
> As far as I can tell, you renamed the wait() and ready() to join() and
> try_join().  In my opinion, these names are far less clear, and again
> my anti-thread-per-invocation bias doesn't like the implied thread
> semantics.

Yes, I could go either way on that one. I opted for consistency with the
join/try_join/timed_join family of thread functions.

> 6) operator R() const;
>
> My opinion here, but if I understand this then the semantics of this
> are far too subtle.
>
> future<int> x = std::fork(myfunc);
> //200 lines later
> z = x + y; // this blocks or throws, mystifying young programmers
> everywhere

Another tradeoff. I think that the implicit conversion here is worth keeping
because the parallelized syntax is closer to the traditional sequential one.
It's a matter of taste.

> Also, what is the meaning of:
> mysubroutine(x) // Does this block or throw, or just use a future
> argument?
>
> What is the meaning if mysubroutine is declared:
> template<T> mysubroutine(T a);

Whether this is a bug or a feature is also a matter of taste. The conversion
allows some mysubroutines to work on a future<X> as if it were an X, doing
the 'obvious' thing.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Marcus Lindblom]

Peter Dimov wrote:
>
> As an aside, does anyone have a success story about active objects? I can't
> seem to grasp their significance; in particular, how are they supposed to
> scale to many cores/HW threads if every access is implicitly serialized?

I don't know if this applies directly, but I've recently looked at
Intel's Thread Building Blocks  and I must say I'm quite impressed how
they've handled things. (It's free to download for evaluation, see
http://www.intel.com/software/products/tbb/)

Their library is solely aimed at parallellizing cpu-limited algorithms
to many cores, by means of a task scheduler and some nifty
breath-first/depth-first evaluation schemes.

It's different from the concept of an 'active object' which may reside
on different threades/processes/cpus/machines/planets, but I think it
could be one direction to think of in terms of futures and how they
spawn recursively to create job objects that are handled by a
thread-pool (typically one thread per core).

The two problems are a bit different, but I just thought I should
mention it here as I liked it a lot and I think a boost-ish
implementation of something similar would be of great value to the world.

Cheers,
/Marcus
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Sohail Somani]

In the spirit of greppability, which is very useful in the case of *_cast, I hope the proposal can be reworked into a syntax that one can grep for when trying to find instances of where a statement may block.

-----Original Message-----
From: boost-bounces@... on behalf of Peter Dimov
Sent: Sat 3/10/2007 5:17 AM
To: boost@...
Subject: Re: [boost] [futures] boost::futures
 
> future<int> x = std::fork(myfunc);
> //200 lines later
> z = x + y; // this blocks or throws, mystifying young programmers
> everywhere

Another tradeoff. I think that the implicit conversion here is worth keeping
because the parallelized syntax is closer to the traditional sequential one.
It's a matter of taste.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[braddock]

Here is another question/comment as I move through this implementation:

I see a strong need for future<void>.

If I build my multi-threaded task scheduling system around future, I will
likely have some invocations which do not return a value, but which I do want
to synchronize with, receive exceptions from, and possibly cancel().

Has there been any work/thoughts how to handle this?  Should future<void> be allowed?

Thanks for the other info Peter and your implementation - very useful.

Braddock Gaskill
Dockside Vision Inc


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Peter Dimov]

Braddock Gaskill wrote:

> Here is another question/comment as I move through this
> implementation:
>
> I see a strong need for future<void>.
>
> If I build my multi-threaded task scheduling system around future, I
> will
> likely have some invocations which do not return a value, but which I
> do want
> to synchronize with, receive exceptions from, and possibly cancel().
>
> Has there been any work/thoughts how to handle this?  Should
> future<void> be allowed?

N2185 does include a future<void> specialization.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost