future.wait() - multiple waiters?

[Tony VE]

Can multiple threads wait on a single future?

I see nothing in the standard preventing it, yet it seems odd when
compared to the 'only one call to get()' rule.

Tony

[Tony VE]

Not to mention that future is movable, but I don't think mutex or
condvar is. So is future the only movable object that I can wait on?
Can I move it while a thread is waiting on it?

[Peter Sommerlad]

Hi Tony,

first of all, since this is about the library part and not the core language, the questions should go to lib-dis...@isocpp.org.

On 22.05.2012, at 08:03, Tony VE wrote:

>
>
> On May 22, 2:00 am, Tony VE <tvane...@gmail.com> wrote:
>> Can multiple threads wait on a single future?

not, if you want to avoid undefined behavior (UB).

a future is a move-only type, this means, "there can be only one". If you leak a future's reference to another thread (not moving the object there), then you are in UB land. The reason for making future move-only, is exactly that it doesn't need additional synchronization to operate on it.

Note that shared_future doesn't provide that kind of synchronization either, it only allows to access the future's result several times. However, if the access is read-only and the underlying result object doesn't contain mutable members you should be fine as in:

" • Access to the result of the same shared state may conflict (1.10). [Note: this explicitly specifies that the result of the shared state is visible in the objects that reference this state in the sense of data race avoid- ance (17.6.5.9). For example, concurrent accesses through references returned by shared_future::get() (30.6.7) must either use read-only operations or provide additional synchronization. — end note ]"

However, you are right that there seems to be no explicit wording prohibiting calling future::wait() from multiple threads and since wait() must synchronize with making the shared state ready anyway, an implementation might provide a useful behaviour. However, I still consider it an error if you leak a future's reference (or address as pointer) to multiple threads.

>>
>> I see nothing in the standard preventing it, yet it seems odd when
>> compared to the 'only one call to get()' rule.
>>
>> Tony
>
> Not to mention that future is movable, but I don't think mutex or
> condvar is. So is future the only movable object that I can wait on?
> Can I move it while a thread is waiting on it?

the last question would mean that you already have leaked its reference to multiple threads.

I am not sure I answered everything, but that is what I can make of it now.

Regards
Peter.

--
Prof. Peter Sommerlad

Institut für Software: Bessere Software - Einfach, Schneller!
HSR Hochschule für Technik Rapperswil
Oberseestr 10, Postfach 1475, CH-8640 Rapperswil

http://ifs.hsr.ch http://cute-test.com http://linticator.com http://includator.com
tel:+41 55 222 49 84 == mobile:+41 79 432 23 32
fax:+41 55 222 46 29 == mailto:peter.s...@hsr.ch

[Ville Voutilainen]

On 22 May 2012 09:03, Tony VE <tvan...@gmail.com> wrote:
> On May 22, 2:00 am, Tony VE <tvane...@gmail.com> wrote:
>> Can multiple threads wait on a single future?

For shared_future, sure. The plain future moves the value when you
get() from it, so subsequent return values of get() would contain
garbage.

>> I see nothing in the standard preventing it, yet it seems odd when
>> compared to the 'only one call to get()' rule.

For shared_future, there is no such rule. :)

> Not to mention that future is movable, but I don't think mutex or
> condvar is.  So is future the only movable object that I can wait on?
> Can I move it while a thread is waiting on it?

unique_lock is movable as well. There's nothing that would prevent
moving from a future during a wait, but you probably don't want to
do anything besides destroy or reassign the moved-from future, but
that's as usual with moved-from values.

[Tony V E]

On Tue, May 22, 2012 at 2:33 AM, Ville Voutilainen <ville.vo...@gmail.com> wrote:

On 22 May 2012 09:03, Tony VE <tvan...@gmail.com> wrote:
> On May 22, 2:00 am, Tony VE <tvane...@gmail.com> wrote:
>> Can multiple threads wait on a single future?

For shared_future, sure. The plain future moves the value when you
get() from it, so subsequent return values of get() would contain
garbage.

waiting is separate from getting (somewhat).  ie you can call wait() without calling get().  The standard says only the first call to get() is valid, but doesn't say the same about wait().  Is that a defect?

 

Tony

[Ville Voutilainen]

On 23 May 2012 05:41, Tony V E <tvan...@gmail.com> wrote:
> waiting is separate from getting (somewhat).  ie you can call wait() without
> calling get().  The standard says only the first call to get() is valid, but
> doesn't say the same about wait().  Is that a defect?

30.6.6 Class template future [futures.unique_future]/2 says

"[ Note: Member functions of future do not synchronize with themselves
or with member functions of
shared_future. — end note ]"

so issuing a wait() simultaneously from multiple threads would seem unwise.
shared_future says instead

"[ Note: Member functions of shared_future do not synchronize with
themselves, but they synchronize with
the shared shared state. — end note ]"