Scott Meyers <usenet@aristeia.com> writes:

> The only motivation I can find for atomic_future is this (from N2997):
>
>    The need for an atomic_future arose from the fact that the move constructor
>    and both assigments made the shared_future much more error prone to use a
>    single instance from multiple threads. But such use is required when more
>    than one thread scans a global list of futures for results
> provided by worker
>    threads.
>
>
> That's a bit terse.  Can somebody please elaborate on the motivation
> for atomic_future?

Every member function of atomic_future is fully synchronized, so if you
call get() whilst another thread assigns a new value to the future then
either you block on the original future or you block on the newly
assigned one, but there is no data race. With a shared_future it is just
the associated state which is synchronized, so calling get() and
operator= concurrently is a data race.

This means that e.g. you can have a global array of atomic_future
objects where each future is assigned individually by a thread as it
creates the task to determine the future value. Another thread that
waits for the values can thus wait on each future without worrying about
the potential for a data race.

Anthony
--
Author of C++ Concurrency in Action | http://www.manning.com/williams
just::thread C++0x thread library   | http://www.stdthread.co.uk
Just Software Solutions Ltd         | http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

The only motivation I can find for atomic_future is this (from N2997):

    The need for an atomic_future arose from the fact that the move constructor
    and both assigments made the shared_future much more error prone to use a
    single instance from multiple threads. But such use is required when more
    than one thread scans a global list of futures for results
provided by worker
    threads.


That's a bit terse.  Can somebody please elaborate on the motivation
for atomic_future?

Thanks,

Scott

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]