[SERVER-40003] Change opCtx waits to always use the fastclock Created: 06/Mar/19 Updated: 06/Dec/22 Resolved: 12/Nov/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Code |
| Affects Version/s: | None |
| Fix Version/s: | features we're not sure of |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Mira Carey | Assignee: | Backlog - Service Architecture |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Service Arch
|
| Backwards Compatibility: | Fully Compatible |
| Participants: |
| Description |
|
Inside the opCtx code, maxtimems and runWithDeadline times are tracked with the fast clock, but opCtx waits are tracked with the precise clock. If it's okay to use the fast clock for hasDeadlineExpired, it's probably okay to use it for timed waits, and we could save ourselves some cycles if it is. |
| Comments |
| Comment by Lauren Lewis (Inactive) [ 12/Nov/21 ] |
|
We haven’t heard back from you for some time, so I’m going to close this ticket. If this is still an issue for you, please provide additional information and we will reopen the ticket. |
| Comment by Mira Carey [ 08/Mar/19 ] |
|
schwerin, I'm hyper aware. redbeard0531 asked me to open this as part of some of the other opCtx changes (because it's a pretty big speed up on systems where reading the clock is slow), but I share your concerns. Current fixVersion is "features we're not sure of" to reflect that. |
| Comment by Andy Schwerin [ 07/Mar/19 ] |
|
The condvar wait used to involve asking the OS to do the waiting, so using its clock (the precise clock) seemed less susceptible to bugs from skew between the two clock sources. Just be careful. |