[JAVA-5140] Replace uninterruptible Lock.lock with Lock.lockInterruptibly Created: 07/Sep/23 Updated: 05/Oct/23 Resolved: 29/Sep/23 |
|
| Status: | Closed |
| Project: | Java Driver |
| Component/s: | Internal |
| Affects Version/s: | None |
| Fix Version/s: | 4.11.0 |
| Type: | Improvement | Priority: | Unknown |
| Reporter: | Valentin Kavalenka | Assignee: | Valentin Kavalenka |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Epic Link: | Virtual Threads Support | ||||||||
| Quarter: | FY24Q3 | ||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Documentation Changes: | Not Needed | ||||||||
| Documentation Changes Summary: | 1. What would you like to communicate to the user about this feature? |
||||||||
| Description |
|
I searched the codebase for use of the Java SE concurrency primitives blocking methods that can't be interrupted (including blocking queues), and Lock.lock is the only method that may be worth replacing. We can analyze whether it is likely that a thread is blocked in Lock.lock by a noticeable duration, or, as we did with synchronized, we can mindlessly replace all the calls with Lock.lockInterruptibly and never use Lock.lock again. I prefer the mindless approach in these two cases. |
| Comments |
| Comment by Githook User [ 29/Sep/23 ] |
|
Author: {'name': 'Valentin Kovalenko', 'email': 'valentin.kovalenko@mongodb.com', 'username': 'stIncMale'}Message: Replace uninterruptible `Lock.lock` with `Lock.lockInterruptibly` (#1206)
|