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

 

    John Souvestre    New Orleans LA, USA    504-454-0899

 

From: John Souvestre <[email protected]> 
Sent: 2026-01-02, Fri 23:15
To: 'Jason E. Aten' <[email protected]>; 'golang-nuts' 
<[email protected]>
Subject: RE: [go-nuts] Re: TryUnlock() and IsLocked() functions

 

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].
To view this discussion visit 
https://groups.google.com/d/msgid/golang-nuts/002701dc7c72%24e6a65a50%24b3f30ef0%24%40Souvestre.com.

Reply via email to