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/
<brjsp>
@K-ballo you said earlier that because of a misunderstanding you have essentially two condition_variable_any
<brjsp>
what should be done about hpx::lcos::local::condition_variable ?
<K-ballo>
should be taken out and shoot at
<K-ballo>
brjsp: in order to truly be a condition_variable, you mena?
<K-ballo>
*mean
<brjsp>
yeah, it totally duplicates std::condition_variable
<K-ballo>
it doesn't, the mutex type ought to be `lcos::local::mutex`, not `spinlock`
<brjsp>
in _any?
<K-ballo>
no, _any needs even more changes
<K-ballo>
or would need
<K-ballo>
std::condition_variable operates on std::mutex
<K-ballo>
lcos::local::condition_variable operates on lcos::local::spinlock rather than lcos::local::mutex
<K-ballo>
the queues and mechanisms condition_variable (the non generic one) is meant to reuse are in mutex, a spinlock does not have those
<K-ballo>
the generic one, on the other hand, may just as well stick to spinlock... possibly... but it ought to use dynamic memory to get some weird corner cases right, it's detailed on the paper I linked the other day I think