[SERVER-28028] reinstate std::timed_mutex Created: 16/Feb/17 Updated: 27/Oct/23 Resolved: 18/Feb/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Concurrency, Portability |
| Affects Version/s: | 3.5.3 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Nathan Myers | Assignee: | DO NOT USE - Backlog - Platform Team |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Operating System: | ALL |
| Steps To Reproduce: | #include <stdx/mutex.h> stdx::timed_mutex mutt; |
| Participants: |
| Description |
|
Since we no longer build with Gcc <4.9, there is apparently, at least by the comment in stdx/mutex.h, no longer a reason to ban std::timed_mutex. Is there any reason to retain stdx/mutex.h at all? Or should uses be changed back to <mutex> and std::mutex? |
| Comments |
| Comment by Nathan Myers [ 18/Feb/17 ] |
|
Withdrawn pending improved stdx/mutex.h facilities unmatched in std. |
| Comment by Andy Schwerin [ 16/Feb/17 ] |
|
I'm not certain we should be using timed_mutex at all. timed_mutex implies that you might have mutexes that are held for a long time, which is strongly discouraged in the mongodb codebase. The preferred course of action is to use a lock in the lock manager, or to do your waiting on condition variables, as both are interruptible via the checkForInterrupt mechanism. If all our stdx concurrency types can switch to std at this point, that would be fine, but I'm not sure that comment is an exhaustive list of problems. |