[SERVER-69178] Interruptible::waitForConditionOrInterruptUntil: Add support for condvar wait without predicate Created: 26/Aug/22 Updated: 05/Dec/22 |
|
| Status: | Open |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Jordi Olivares Provencio | Assignee: | Backlog - Service Architecture |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Assigned Teams: |
Service Arch
|
||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
As part of This ticket is about exposing an interface for such cases where you can wait without a predicate, exposing yourself to spurious wake-ups. |
| Comments |
| Comment by Jason Chan [ 06/Sep/22 ] |
|
Putting this in top priority to investigate within the next sprint |
| Comment by Jordi Olivares Provencio [ 30/Aug/22 ] |
|
We are indeed implementing a semaphore, but with scheduling support. We couldn't use any existing implementation since it's quite tailored to this use-case. |
| Comment by Billy Donahue [ 29/Aug/22 ] |
|
I still don't get it. The operation you're describing sounds like a semaphore, not a condition variable. Would that be a better fit for you? I feel like condition variable does what it's designed to do, and this is not that. |
| Comment by Jordi Olivares Provencio [ 29/Aug/22 ] |
|
billy.donahue@mongodb.com To clarify, in that ticket we still check some conditions (a predicate if you want) before deciding to wait again or not. The thing is that we need to do some extra work before proceeding to wait again. The principle behind the phrase "just the simple act of waking the thread has to have side effects" is due to a required feature in the ticket where we need to implement our own version of cv.notify_one() that returns whether it will wake a thread up or not. To do this we have a counter that goes up with notifies and down to 0 with threads waking from the notifications. This is the reason why we can't use the current interface as we have no control of this side effect of waking. It could be argued that this should be a method of the condition_variable object, but it might be quite complex to implement in general without knowledge of how it's going to be used. |
| Comment by Billy Donahue [ 26/Aug/22 ] |
That sounds like a misuse of condition_variable notifications. The notification is nothing but a means of getting waiters to look at other conditions and data to determine whether to wake up. The notify is never itself something to respond to directly. Waiting with or without a predicate is a style choice. If you don't choose to use a predicate you're still expected to check other conditions and data warrant the wakeup of your thread or whether it should relock and go back to sleep. In either case the action you want the thread to take on wakeup should not happen until the condition of the condition variable is satisfied or timeout has been reached. "just the simple act of waking the thread has to have side effects" is the most important thing about this ticket and I would like to understand it before digging deeper. |
| Comment by Billy Donahue [ 26/Aug/22 ] |
|
Thanks for clarifying. I updated the title. Still wondering about: "just the simple act of waking the thread has to have side effects" In any case maybe the presence or absence of a predicate is an obscure way to specify that behavior. Apologies for what might be silly questions, but I don't understand this request or the waitForConditionOrUntil function super-well. I'm just trying to understand the ticket. |
| Comment by Jordi Olivares Provencio [ 26/Aug/22 ] |
|
I'm referring to the Interruptible::waitForConditionOrUntil interface. Essentially we have a use-case where we want to be susceptible to interruptions (timeouts, killing the operation, etc.) and have a deadline but we can't really use the predicate in a meaningful manner because just the simple act of waking the thread has to have side effects. |
| Comment by Billy Donahue [ 26/Aug/22 ] |
|
I suspect I don't understand the request. Can you clarify? It feels like what your asking for and what I think you're asking for are different things. What do you mean by "the current interface for waiting on a condition variable"? You can cv.wait without a predicate if you want to. A condition variable wait predicate should not be signalling anything or have side effects, whether it passes or fails. If some code has to run after the condition variable wait() completes (e.g. to signal something), would it work to just place it after the wait statement? A predicate doesn't expose you to spurious wake-ups, it's a means of suppressing them. So I'm not sure what that means. |