Thank you Ian.
I guess I was wondering still if we had existing code with multiple mutexes
being locked or rLocked where we didnt have the defer unlocks and those
panic.
I guess I dont understand why you would want the lock entirely for the
entire execution of the function until the defer. It seems more efficient
to only Lock and unlock between the specific lines of code where you are
mutating a shared variable.
Still my question would be the same, on these existing locks if a panic
happened and it exited prematurely, is it just safe to put any mutexes we
are locked or RLocked inside of the recover if statement? Just in case
those are Locked or RLocked, will an Unlock or RUnlock always be okay and
not panic further if they are not locked and we call Unlock or RUnlock?
I swear I have seen golang get mad when you try to unlock something that
has not been locked. So I am trying to envision more the best way about
this.
I think its too risky right now to convert all UnLocks and RUnlocks to a
defered unlock because we have been through so many deadlock situations in
the past. I am a bit reluctant to keep something locked for the entire
execution of a function everywhere.
On Tuesday, October 17, 2017 at 8:15:23 PM UTC-4, David Renne wrote:
>
> Hi there,
>
> I was wondering if the code ever panics and we have a if recover :=
> recover(); recover != nil {
>
> in a defer func and we are using sync.RWMutexes which do not have a defer
> to unlock for example.
>
> What kinds of things can happen if the code unexpectedly panics when we
> are in a Lock() in the code and then something panics before it Unlocks.
> My defer funcs almost never unlock the syncRW mutexes or any RLock()'s that
> were called to unlock.
>
> Should maybe if we are in the recover() block should we then call Unlock()
> or RUnlock on all sync.RWMutex's that the function is recovering from? How
> would one know if you are in a lock or not if we made it far enough to open
> the lock to know which ones to unlock if it truly keeps the lock open?
>
> Since we rarely get panics and we are dealing with some deadlocks, I am
> asking myself this question and dont really know how to test it easily to
> verify what really happens.
>
--
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.
