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(&m.state, 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:[email protected]]
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 [email protected].
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
