Timeline for design pattern to avoid deadlock with mutex in golang
Current License: CC BY-SA 4.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 8, 2023 at 6:55 | audit | Suggested edits | |||
| Aug 8, 2023 at 6:56 | |||||
| Jul 20, 2023 at 20:06 | comment | added | JimmyJames | I'm not very familiar with golang but if you have some sort of thread id, you could keep a dictionary of threads to held locks. If that works, you can surely build a simple function which abstracts the check to see if the current thread already has a lock on the mutex before attempting to acquire it. It kind of seems like that should be automatic though. That is, a thread trying to acquire a lock it already holds should be a no-op. | |
| Jul 20, 2023 at 17:07 | answer | added | gnasher729 | timeline score: 0 | |
| Jul 20, 2023 at 16:55 | answer | added | amon | timeline score: 4 | |
| Jul 20, 2023 at 16:02 | review | Close votes | |||
| Aug 4, 2023 at 3:08 | |||||
| S Jul 20, 2023 at 15:37 | review | First questions | |||
| Jul 20, 2023 at 17:10 | |||||
| S Jul 20, 2023 at 15:37 | history | asked | cylon86 | CC BY-SA 4.0 |