I hear you. I have developed work-arounds for the 2 situations I have in a
program that I’m currently working on. But TryLock() caught my attention and
it seemed that using it as a basis I could build the other two functions I
needed, based on it.
What situations? 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.
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. Other solutions I used before v.18 add
TryLock() worked, but added complexity.
I have an understanding of races. But it seems to me that TryLock() solves
this for itself. And I’m building on top of it.
John
John Souvestre New Orleans LA, USA 504-454-0899
From: Robert Engels <[email protected]>
Sent: 2026-01-02, Fri 23:30
To: John Souvestre <[email protected]>
Cc: Jason E. Aten <[email protected]>; golang-nuts
<[email protected]>
Subject: Re: [go-nuts] Re: TryUnlock() and IsLocked() functions
As Jason said it might be easier to go up a level and describe the problem
you’re trying to solve. It is trivial to use a mutex to coordinate safely so
it’s a bit unclear why you are complicating it with another layer. If you are
trying to have things not block that is trivial too.
Your basic problem is you are trying to ask is access available then get access
- which is inherently racy. Breyer to just request access, and return try or
false if it was granted - using TryLock and if true use defer to schedule the
unlock.
On Jan 2, 2026, at 11:15 PM, 'John Souvestre' via golang-nuts
<[email protected] <mailto:[email protected]> > wrote:
Hi Jason.
I see what you are saying. Ok. One idea: What if everyone else using this
mutex used only the TryLock and TryUnlock functions and proceeding only if they
returned “success”. Then they would be honoring any pre-existing, or
non-existing, lock.
This certainly isn’t what I originally had in mind, but it would be possible to
make the changes.
John
John Souvestre New Orleans LA, USA 504-454-0899
From: [email protected] <mailto:[email protected]>
<[email protected] <mailto:[email protected]> > On Behalf
Of Jason E. Aten
Sent: 2026-01-02, Fri 21:01
To: golang-nuts <[email protected]
<mailto:[email protected]> >
Subject: [go-nuts] Re: TryUnlock() and IsLocked() functions
The main difficulty is here is akin to a use-after-check race.
After you have done an Unlock, any other goroutine could have grabbed the lock,
so returning false does not mean the lock is available.
In fact it means nothing meaningful... unless you have otherwise guaranteed no
lock contention, right? And if you've already guaranteed no contention by
another mutex, why bother with this one?
If you expand on your larger goal, we might be able to suggest
an approach that avoids TryLock.
On Friday, January 2, 2026 at 11:42:24 PM UTC-3 John Souvestre wrote:
Hi all.
I have a question about the mutexes provided by the sync library. It is
correct to say that using the 3 lines of code below, anywhere in Go code, won't
have any effect, other than to introduce a slight, non-blocking delay while
they execute? In other words, the mutex is guaranteed to be the same before
and after, and won’t hang your code, regardless of what else is going on,
including in other GoRoutines.
// Note: x is a sync.Mutex.
if x.TryLock() {
// x was unlocked but is now locked by us.
x.Unlock()
}
If so, then would these functions be non-blocking, correct, and safe to use?
// Note: x will always be unlocked upon return.
func TryUnlock(x *sync.Mutex) (success bool) {
if x.TryLock() {
// x was unlocked but is now locked by us.
x.Unlock()
return true
}
// x was unlocked to start with.
return false
}
// Note: x will be the same (locked or unlocked) upon return.
func IsLocked(x *sync.Mutex) (locked bool) {
if x.TryLock() {
// x was unlocked but is now locked by us.
x.Unlock()
return false
}
// x was locked to start with.
return true
}
I do understand that what I'm trying to achieve here is ok to do in only rare
cases. Indeed, I've only found a need for them and TryLock() on a few rare
occasions.
Thanks,
John
John Souvestre New Orleans LA, USA 504-454-0899
<tel:(504)%20454-0899>
--
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]
<mailto:[email protected]> .
To view this discussion visit
https://groups.google.com/d/msgid/golang-nuts/b0d6a801-7799-4119-b5fa-24e77db4863en%40googlegroups.com
<https://groups.google.com/d/msgid/golang-nuts/b0d6a801-7799-4119-b5fa-24e77db4863en%40googlegroups.com?utm_medium=email&utm_source=footer>
.
--
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]
<mailto:[email protected]> .
To view this discussion visit
https://groups.google.com/d/msgid/golang-nuts/002101dc7c6f%24e7210ff0%24b5632fd0%24%40Souvestre.com
<https://groups.google.com/d/msgid/golang-nuts/002101dc7c6f%24e7210ff0%24b5632fd0%24%40Souvestre.com?utm_medium=email&utm_source=footer>
.
--
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/002c01dc7c74%24834574d0%2489d05e70%24%40Souvestre.com.
