Le 12/10/15 14:52, Hartmut Kaiser a écrit :
Sorry for cross-posting.
Vicente J. Botet Escriba wrote:
I have a branch (https://github.com/boostorg/thread/tree/feature/non_blocking_futures) that don't blocks on any future, but this will break async. FWIW, the design decision to let those (and only those) futures block on destruction which are returned from async was one of the really bad decisions made for C++11, however that's just my opinion (others agree, but yet others disagree). This flaw essentially caused us to spend many committee hours on discussions how to mitigate the situation, with proposed solutions ranging from 'leave it be as is' to as extreme as 'deprecate it now'. There seems to be a growing consensus however to develop other constructs which eventually could replace async, such as executors, etc. I'm a proponent of following that path. Hi Hartmut,
I can agree with you at the C++ standard level, but I have a library to maintain, and I have introduced a very BIG BUG making all the futures block on destruction (develop branch). Now, there is a major need to make the futures returned by then() to be non-blocking. The branch non_blocking_futures has the opposite. However, there are people that would like that the boost::async follows the standard. So, I don't know what to do, fix future::then() and break async(), or deliver the fiw only when async will conform to the standard; knowing that this behavior might be deprecated in 2017. I need the feedback from the Boost community respect to this point.
More generally, I strongly believe that we have to come up with a _coherent story_ for all kinds of (higher-level) parallelism in C++: task-based parallelism, asynchronous, continuation style programming, fork-join parallelism of heterogeneous tasks, simple fork-join (iteration based) parallelism, etc. All of this has to go hand in hand with a (orthogonal) vectorization story. We also need to think about integrating GPUs.
The goal has to be to make parallelism in C++ independent of any external solutions such as OpenMP, OpenACC, etc.
Many of the building blocks for this are already being discussed: executors and executor_traits for customizing the 'how and where' of task execution, executor parameters for grain-size control, and execution policies as the higher level facility allowing to tie everything together (see for instance HPX [7]).
We (as a committee) already allow for passing execution policies as the first argument to parallel algorithms (Parallelism TS, N4505 [2]). We already have some facilities for task-based, asynchronous, and continuation style parallelism in place (Concurrency TS, N4501 [3]).
We have a paper proposing task_blocks for fork-join parallelism of heterogeneous tasks (N4411 [4]). We have two competing (but converging) efforts for defining an executor concept (N4406 [5], PR0008R0 [6]).
I'm aware of most of them if not all. I've been implementing/introducing some of these facilities in Boost.Thread recently. I have not implemented the parallel algorithms yet, as this will require time I don't have now. I'm aware of these proposals, and as others I'm experimenting as we don't know yet what would be the final interface.
We have a (strong) proposal for simplifying continuation based programming (await, PR0057R0 [8]).
We have attempts on integrating executors with existing facilities (Boost, HPX). A pointer? We miss work on parallel ranges. We miss work on integrating data structures with data placement policies in conjunction with executors. We miss work on extending all of this to many-core, distributed, and high-performance computing.
Etc.
We (as a community) really need a higher level, over-arching approach which ties all of the above together! My plan is to work on a corresponding concept paper by the time of the committee meeting end of February 2016. I plan to update the N4414 Executors and Schedulers Revision 5 proposal as I believe that Executors must be copyable and lightweight. The new proposal P0008R0 comes back to executors that are not copyable and so left the responsibility of the the lifetime to the user (I'm experimenting it in branch make_executors_copyable) Our group has outlined our current understanding and a possible approach to this here [1]. I'd like for this to be understood as a seed for a wider discussion. Needless to say, I'd very much like to collaborate on this with anybody interested in joining the effort. I'll read it and come back to you.
Best, Vicente
Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu
[1] http://stellar.cct.lsu.edu/pubs/executors_espm2_2015.pdf [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4505.pdf [3] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4501.html [4] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4411.pdf [5] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4406.pdf [6] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0008r0.pdf [7] http://stellar-group.github.io/hpx/docs/html/hpx/manual/parallel.html [8] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0057r0.pdf
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost