Hi John, you seem to be asking if the API documentation is correct... which is a little... odd... so I'm trying to get a clearer picture of the problem. Yes, if TryUnlock returns true, then you have the lock.
"TryLock tries to lock m and reports whether it succeeded." -- https://pkg.go.dev/sync#Mutex.TryLock > Another situation is about trying to decide what can data can be displayed and what can’t, with the display routing running in its own GoRoutine, triggered by a timer tick. The data being changed is protected by a mutex which can sometimes be locked while a user edits it. I can’t have the display updates simply stop and wait. The TryLock() lets me know if I can lock, and display, or if I should skip over that data. This seems reasonable to me. > One is trying to use defers when the code is flipping the lock on and off a few times. It gets messy fast. A single TryUnlock() eliminates that complexity. It can be simpler just to manually (Lock and Unlock) in multiple places if one defer doesn't handle it for the whole function. With regards to your specific question about your assertions: [1] "// x was unlocked but is now locked by us." my answer: [1] is true. [2] "// Note: x will always be unlocked upon return." my answer: [2] is false because another goroutine could now hold the lock by the time the function returns. The lock could have been grabbed after the first goroutine unlocked but before it returned, and the other goroutine could be at the point labelled "// x was unlocked but is now locked by us." [3] // Note: x will be the same (locked or unlocked) upon return. my answer: [3] is true. [4] // x was unlocked to start with. my answer: [4] is false because the TryLock failed, so the x was Locked when [4] was reached. [5] // Note: x will be the same (locked or unlocked) upon return. my answer: [5] is true. [6] // x was locked to start with. my answer: [6] is true. IsLocked() is problematic name... WasLocked() would seem more accurate. Are you seeing some kind of problem in your actual use that is prompting your queries? On Saturday, January 3, 2026 at 2:37:10 AM UTC-3 John Souvestre wrote: Hi again. Ignore my 1st reply. I posted that without thinking about it enough. Let me ask this: What do you say about my first question. Are my assertions about sync’s TryLock() correct? Is there any way that it can fail? This question says that you do not proceed arbitrarily after the TryLock(), but only if it succeeded. In that case, nobody can lock. And nobody else is going to try to Unlock(), since they don’t hold a lock. It seems to me that this must be true, but if not them the rest of what I did certainly won’t work. John -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/4863c08c-414c-4519-827b-62bd89f3148bn%40googlegroups.com.
