Re: [go-nuts] Re: There has no Mutex.Trylock() implemention or similar method ?

[adonovan via golang-nuts]

On Sunday, 23 October 2016 16:17:29 UTC-4, John Souvestre wrote:
>
> Take a look at https://github.com/LK4D4/trylock/blob/master/trylock.go .
>
>  
>
> I believe that it is easier and performs better.
>

Yes, this looks like a sound solution if you don't need the re-entrant 
behavior.

-- 
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: [go-nuts] Re: There has no Mutex.Trylock() implemention or similar method ?

[John Souvestre]

Take a look at https://github.com/LK4D4/trylock/blob/master/trylock.go .

 

I believe that it is easier and performs better.

 

John

John Souvestre - New Orleans LA

 

From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On 
Behalf Of djad...@gmail.com
Sent: 2016 October 23, Sun 10:30
To: golang-nuts
Subject: [go-nuts] Re: There has no Mutex.Trylock() implemention or similar 
method ?

 


Hi,

Trylock is simple as: https://play.golang.org/p/rpy3Kg1KWW

 

Regards,

Djadala

 

-- 
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: There has no Mutex.Trylock() implemention or similar method ?

[djadala]

Hi,

Trylock is simple as: https://play.golang.org/p/rpy3Kg1KWW

Regards,
Djadala

-- 
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: [go-nuts] Re: There has no Mutex.Trylock() implemention or similar method ?

[John Souvestre]

I understand what you are saying with regard to a reentrant type of mutex.  But 
how about a non-reentrant mutex, as Go currently has?  Borrowing from an old 
message by Luke Scott:

 

> I was looking at the sync package's Lock function, and it does 

 > almost the same thing.

> It looks like a TryLock function would look like this:

> 

 > func (m *Mutex) TryLock() bool {

> return atomic.CompareAndSwapInt32(, 0, mutexLocked)

> }

> 

 > Is this correct? If so, what's the problem?

 

I don’t recall seeing an answer to his question, however.

 

John

John Souvestre - New Orleans LA

 

From: adonovan via golang-nuts [mailto:golang-nuts@googlegroups.com] 
Sent: 2016 October 23, Sun 07:39
To: golang-nuts
Subject: [go-nuts] Re: There has no Mutex.Trylock() implemention or similar 
method ?

 

On Friday, 21 October 2016 09:05:10 UTC-4, Michael Liu wrote:

I've a race scenario used with Mutex.Lock with Lock() and Unlock(). now 
multi-routines try to lock the resource and start a few logical code if the 
Lock.Lock() succesfully. other routines don't need to block util Lock.Unlock() 
that they can do the above logicals with next time or in future(logical may 
changes some variables and those variables' change could be see with latency). 
That looks like a Trylock() implemetion.

 

One reason the TryLock method does not exist is that its behavior cannot be 
expressed without reference to some notion of goroutine identity.  That is, its 
doc comment would read "succeeds immediately if the current goroutine already 
holds the lock".  The designers of the language have strived to avoid making 
goroutine state relevant to the behavior of any function since it makes 
programs had to reason about and prevents programmers from freely moving work 
to a different goroutine.

 

Another reason is described in Chapter 9 of our book (gopl.io): "There is a 
good reason Go’s mutexes are not re-entrant. The purpose of a mutex is to 
ensure that certain invariants of the

shared variables are maintained at critical points during program execution. 
One of the invariants is “no goroutine is accessing the shared variables,” but 
there may be additional invariants specific to the data structures that the 
mutex guards. When a goroutine acquires a mutex lock, it may assume that the 
invariants hold. While it holds the lock, it may update the shared variables so 
that the invariants are temporarily violated. However, when it releases the 
lock, it must guarantee that order has been restored and the invariants hold 
once again. Although a re-entrant mutex would ensure that no other goroutines 
are accessing the shared variables, it cannot protect the additional invariants 
of those variables."

 

 

-- 
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: There has no Mutex.Trylock() implemention or similar method ?

[adonovan via golang-nuts]

On Friday, 21 October 2016 09:05:10 UTC-4, Michael Liu wrote:
>
> I've a race scenario used with Mutex.Lock with Lock() and Unlock(). now 
> multi-routines try to lock the resource and start a few logical code if the 
> Lock.Lock() succesfully. other routines don't need to block util 
> Lock.Unlock() that they can do the above logicals with next time or in 
> future(logical may changes some variables and those variables' change could 
> be see with latency). That looks like a Trylock() implemetion.
>

One reason the TryLock method does not exist is that its behavior cannot be 
expressed without reference to some notion of goroutine identity.  That is, 
its doc comment would read "succeeds immediately if the current goroutine 
already holds the lock".  The designers of the language have strived to 
avoid making goroutine state relevant to the behavior of any function since 
it makes programs had to reason about and prevents programmers from freely 
moving work to a different goroutine.

Another reason is described in Chapter 9 of our book (gopl.io): "There is a 
good reason Go’s mutexes are not re-entrant. The purpose of a mutex is to 
ensure that certain invariants of the

shared variables are maintained at critical points during program execution. 
One of the invariants is “no goroutine is accessing the shared variables,” 
but there may be additional invariants specific to the data structures that 
the mutex guards. When a goroutine acquires a mutex lock, it may assume 
that the invariants hold. While it holds the lock, it may update the shared 
variables so that the invariants are temporarily violated. However, when it 
releases the lock, it must guarantee that order has been restored and the 
invariants hold once again. Although a re-entrant mutex would ensure that 
no other goroutines are accessing the shared variables, it cannot protect 
the additional invariants of those variables."



-- 
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: There has no Mutex.Trylock() implemention or similar method ?

[Henrik Johansson]

There was a long thread just recently about SpinLocks and the memory model.
There are several implementations on github. I cannot vouch for the quality
of any of them.

fre 21 okt. 2016 kl 16:14 skrev Roberto Zanotto :

> Maybe you can solve this with atomics.
> You keep an int32 that acts as mutex (0 is unocked, 1 is locked),
> the Trylock is done with atomic.CompareAndSwapInt32(mu, 0, 1) and the
> Unlock with atomic.StoreInt32(mu, 0).
> This gives you a Trylock, but you lose the standard (blocking) Lock.
>
> You may have to put your "usage" variable inside an atomic.Value,
> if some goroutines want to read it while another is modifying it.
> Be sure to test your code with -race.
>
>
> On Friday, October 21, 2016 at 3:05:10 PM UTC+2, Michael Liu wrote:
>
> I've a race scenario used with Mutex.Lock with Lock() and Unlock(). now
> multi-routines try to lock the resource and start a few logical code if the
> Lock.Lock() succesfully. other routines don't need to block util
> Lock.Unlock() that they can do the above logicals with next time or in
> future(logical may changes some variables and those variables' change could
> be see with latency). That looks like a Trylock() implemetion.
> I browsed the discussion
> https://groups.google.com/forum/#!searchin/golang-nuts/trylock%7Csort:relevance/golang-nuts/MTaJNZ49u60/ycc7UHgjLwgJ
> and
> guess Trylock() may the best way ...
>
> var lock sync.Mutex
>
> func change(vvv int) bool {
>  if lock.Trylock() {
>   // execute codes if we trylock successfully
>   bla bla...
>   usage := vvv ...
>   bla bla...
>
>   return true
>  } else {
>   // someone is locking the resource. we skip the
>   // change() call. and take a chance in next
>   // time. the context of this method we can drop
>   // directly
>
>   return false
>  }
> }
>
> routines := 16
>
> for ;routines != 0; routines-- {
> go func() {
> // infinite loop
> var i = 0
> for {
> // discard the return value of change()
> change(i)
> i++
> }
> }()
> }
>
> --
> 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 golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: There has no Mutex.Trylock() implemention or similar method ?

[Roberto Zanotto]

Maybe you can solve this with atomics.
You keep an int32 that acts as mutex (0 is unocked, 1 is locked),
the Trylock is done with atomic.CompareAndSwapInt32(mu, 0, 1) and the 
Unlock with atomic.StoreInt32(mu, 0).
This gives you a Trylock, but you lose the standard (blocking) Lock.

You may have to put your "usage" variable inside an atomic.Value,
if some goroutines want to read it while another is modifying it.
Be sure to test your code with -race.

On Friday, October 21, 2016 at 3:05:10 PM UTC+2, Michael Liu wrote:
>
> I've a race scenario used with Mutex.Lock with Lock() and Unlock(). now 
> multi-routines try to lock the resource and start a few logical code if the 
> Lock.Lock() succesfully. other routines don't need to block util 
> Lock.Unlock() that they can do the above logicals with next time or in 
> future(logical may changes some variables and those variables' change could 
> be see with latency). That looks like a Trylock() implemetion.
> I browsed the discussion 
> https://groups.google.com/forum/#!searchin/golang-nuts/trylock%7Csort:relevance/golang-nuts/MTaJNZ49u60/ycc7UHgjLwgJ
>   
> and
>  
> guess Trylock() may the best way ...
>
> var lock sync.Mutex
>
> func change(vvv int) bool {
>  if lock.Trylock() {
>   // execute codes if we trylock successfully
>   bla bla...
>   usage := vvv ...
>   bla bla...
>
>   return true
>  } else { 
>   // someone is locking the resource. we skip the 
>   // change() call. and take a chance in next
>   // time. the context of this method we can drop
>   // directly
> 
>   return false
>  }
> }
>
> routines := 16
>
> for ;routines != 0; routines-- {
> go func() {
> // infinite loop 
> var i = 0
> for {
> // discard the return value of change()
> change(i)
> i++
> }
> }()
> }
>

-- 
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.