@mperham if you're curious, the benchmarks weren't particularly encouraging: https://github.com/tarcieri/fastcondition/commit/951d6b25ce34b3c4c59a51fcebf8cf9b80611b27 … /cc @halorgium @evanphx
@evanphx @mperham @halorgium unless I'm mistaken, that's what it's doing every time cond.wait(mutex) is called
-
-
@bascule@mperham@halorgium You're locking after a wait. The mutex is auto-locked after wait. How do you lock before the user does work? -
@evanphx@mperham@halorgium it should be releasing after the wait, and allowing the signaling thread to run -
@bascule@mperham@halorgium Read the man page. cond_wait unlocks the mutex, waits, then relocks the mutex on resume. -
@evanphx@mperham@halorgium confirm, then the first thing the benchmark does after that is unlock the mutex -
@bascule@mperham@halorgium I'm just saying, if you want to use this for real, you need to separate the locking operation from the wait.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.