Boost logo

Boost :

Subject: Re: [boost] [next gen future-promise] What to call themonadicreturntype?
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2015-05-25 23:50:36

Can't use a spinlock pool. Because you might hold the spin lock when
moving/copying T, and T could be anything, then, in theory at least, T's
constructor might also use a future/promise, etc, etc, such that a
collision could cause a deadlock.

And extremely rare deadlock. That a user would never be able to diagnose.

Alternatively, with a lock in each and pointers pointing to each other, you
avoid deadlock by first setting (via CAS) your own state to be "I'm moving"
then (if successful) setting your partner's flag to "see ya later", then
(if successful) moving.

No one moves without telling the other first. You can get a live lock, but
not a dead lock. The live Lock can be dealt with (particularly easily since
the relationship (promise vs future) is asymmetrical - just say future
always goes first, for example).

At least that's one way:

Sent from my portable Analytical Engine

*From:* "Peter Dimov" <lists_at_[hidden]>
*To:* "boost_at_[hidden]" <boost_at_[hidden]>
*Sent:* 25 May, 2015 7:59 PM
*Subject:* Re: [boost] [next gen future-promise] What to call

> Seems to me that future and promise both first need to take their spinlock
> and then the other's, which creates the potential for deadlock.

You could fix that by preallocating a sufficiently big static array of
spinlocks, then generating an index when creating the promise and using
spinlock_[i] in both. Collisions are possible but harmless.

This non-allocating implementation is an interesting argument in favor of
the current "unique future", which I've long disliked. I prefer futures to
be shared_futures. That may too be possible to implement without allocation,
but it's kind of complicated.

Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at