consider wrap bt:condition-wait in a loop
hxzrx opened this issue · comments
Hi, this issue may relate to bordeaux-threads' issue 29, where you left an discussion and you said APIv2 worked.
In cl-gserver, bt:condition-wait was used directly (src/queue/queue.lisp), however, according to my tests, spurious wakeups may occur even with APIv2. I raised an issue for bordeaux-threads with my test code, and the author confirmed that it's right to use condition-wait in a loop.
I don't know why the same test code failed in my laptop and why it passed in the author's laptop, however, I think it's better to wrap condition-wait within a loop. The missed signals and spurious wakeups of condition variable wasted me a lot of time when I used it in a thread pool as they occured very very rarely.
Hi.
I can't recall exactly. But I believe I tried a condition-wait loop, but as can be seen, it is commented out, because it caused all queue tests and hence actor tests to fail making dequeing unreliable.
So I don't know. What I can say is, it works as it is right now.
If you can make it work I'll happily accept a PR.
Hi,
I ran the tests in CCL with the vanilla codes, and all tests passed except counter-mp-unbounded--mixed.
I've created a PR, all tests passed in SBCL. However, in CCL, counter-mp-unbounded--mixed still failed, and the others passed as they were, but I think it's nothing to do with condition-wait.
The problem your previously commented code was, (dequeue/wait queue cvar lock) dequeued once, and the subsequent (dequeue/no-wait queue) dequeued once more.
PS. If I increment the utils:assert-cond's max-time argument to 10 in the last line of counter-mp-unbounded--mixed, all tests will pass in CCL. My dev env is a vm hosted in win10, I think it's too slow for CCL.
PS. If I increment the utils:assert-cond's max-time argument to 10 in the last line of counter-mp-unbounded--mixed, all tests will pass in CCL. My dev env is a vm hosted in win10, I think it's too slow for CCL.
Possibly. It's good that it'll pass when you increase the timeout.
#53 was merged.
Thanks for your contribution.