On Wed, Oct 18, 2017 at 7:46 AM, David Renne <davidre...@gmail.com> wrote: > > 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.
Yes, sometimes. When you need to be careful about panics you can use a helper function or a function literal. > 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? No. You must not call Unlock on a mutex that is not locked. Ian -- 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.
