aserio changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar.cct.lsu.edu | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | Buildbot: http://rostam.cct.lsu.edu/ | Log: http://irclog.cct.lsu.edu/
mcopik has quit [Ping timeout: 265 seconds]
daissgr has quit [Quit: WeeChat 1.4]
parsa has joined #ste||ar
<hkaiser>
heller: it might be a terminology thing
<hkaiser>
based on the way I use the terminology, 'The future<> is all about concurrency' is wrong, it's rather 'The future<> is all about parallelism' or 'The future<> is all about asynchrony'
<zao>
The future<> is hoarding exceptions to unleash on you when you least want them.
<brjsp>
could anyone explain to me why does this code use two locks?
<K-ballo>
if I recall correctly, because of a misunderstanding that left us with essentially two `condition_variable_any`
parsa has quit [Quit: Zzzzzzzzzzzz]
<K-ballo>
there's a paper on why a `condition_variable_any` needs a separate internal lock, I can dig it up
<K-ballo>
basically `condition_variable` is meant to share the queues with the given `mutex`, whereas `condition_variable_any` is meant to be generic so in order to be able to operate with the underlying system it needs a separate lock
<K-ballo>
but we chose the wrong kind of mutex for `condition_variable`