On Tue, May 26, 2015 at 6:36 AM, Peter Dimov
Gottlob Frege wrote:
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.
Yes, good point. Need recursive spinlocks.
I don't think a pool of recursive spinlocks works, because T could decide to wait on another thread, which is waiting on a future, which could - behind the scenes - be using the same spinlock as the original thread. You could probably still use a pool somehow, with more management, but it gets complicated. You probably either need at least as many locks as threads, or a fall back of allocating a lock if none are available - but the original point was to not allocate... (Or a way to know that Thread A is waiting on Thread B...) Tony