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: http://2013.cppnow.org/session/non-allocating-stdfuturepromise/ Sent from my portable Analytical Engine ------------------------------ *From:* "Peter Dimov" <lists@pdimov.com> *To:* "boost@lists.boost.org" <boost@lists.boost.org> *Sent:* 25 May, 2015 7:59 PM *Subject:* Re: [boost] [next gen future-promise] What to call themonadicreturntype?
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: http://lists.boost.org/mailman/listinfo.cgi/boost