Timeline for Maintaining locks across abstraction
Current License: CC BY-SA 4.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 6, 2023 at 12:59 | comment | added | Useless | It sounds like you have so much contention your performance is already probably compromised. If you're holding a lock for a long time, the preferred solution is to just stop doing that. | |
| Nov 6, 2023 at 12:15 | comment | added | CygnusX1 | This varies. The most typical case is that they are called together, but the scope of mutexes varies. For example, cleanup may be using a single application-wide mutex, while doStuff is per-task mutex. Holding both for the duration of both functions would kill benefits of multithreading in this case. | |
| Nov 5, 2023 at 13:15 | comment | added | Useless | Are the two lower level functions only called together, or also independently? If they're only called together there's no penalty for holding both locks for the compound operation anyway. Even if they are called independently, there's no penalty unless it causes contention in practice. | |
| Nov 5, 2023 at 12:08 | comment | added | CygnusX1 | I did not recognize how crucial that part was when I posed the question. I edited the question, to make it more explicit what was previously only implied by function names. (The edit itself is also explicit as not to confuse future readers) | |
| Nov 5, 2023 at 10:39 | comment | added | Useless | But "that part" is crucial. If you under-specify the question, you get a more general answer than you need. | |
| Nov 5, 2023 at 8:28 | comment | added | CygnusX1 | Why locking both for the full duration is the only way? Why lock(p)-doStuff-lock(q)-unlock(p)-cleanup-unlock(q) is not sufficient? I do not worry about order of invocation doStuff and cleanup. You are never going to call them in reverse order, but for the sake of simplicity of the example I skipped that part. | |
| Nov 5, 2023 at 0:00 | comment | added | Useless | If you can change p & q to both use the same mutex, that also sidesteps the problem. It's still a change to the low level components though. You can't just add a third mutex unless you know the low level components will never be used without it | |
| Nov 4, 2023 at 23:06 | comment | added | Basilevs | Why do we need to expose the locks? Can't we introduce a third mutex to handle higher level operations without invasive changes to low level components? | |
| Nov 4, 2023 at 13:24 | comment | added | Useless | Specifically your suggestion doesn't work in general because you can't prevent deadlock between two threads calling the functions in opposite order to one another. Generalized deadlock-proofing requires the locks to be acquired always in the same order, not in the order you arrange your function calls. | |
| Nov 4, 2023 at 13:20 | comment | added | Useless | Locking both for the full duration is the only way to avoid the problem you identified, though. If that leaves the locks held for too long, you need to refactor the work so that more of it can be done without holding the lock in the first place. | |
| Nov 4, 2023 at 10:56 | comment | added | CygnusX1 | The latter question was more as a concrete example of the former, thank you for a different approach to it though! However, with the former, general question - if I understand correctly, you suggest to lock both locks for the full duration of both functions? My goal is to lock q and then unlock p right after that. I don't want to lock both p and q during full execution of both functions. | |
| Nov 4, 2023 at 0:33 | history | edited | Useless | CC BY-SA 4.0 | added 389 characters in body |
| Nov 4, 2023 at 0:27 | history | answered | Useless | CC BY-SA 4.0 |