sync: add Mutex.MustBeLocked

[msolo]

To prevent careless programming, I want to panic if a lock is not held at a certain
point.

I could see the rationale for making this panic and renaming the method MustBeLocked()
or PanicIfUnlocked(). I can't think of too many valid use cases other than panicking.

I can see people not reading it carefully and assuming that !IsUnlocked() means that
they hold the lock, or that if IsUnlocked() { Lock() } would only lock if you weren't
already.



diff -r 23006c94f1aa src/pkg/sync/mutex.go
--- a/src/pkg/sync/mutex.go Fri Dec 17 14:00:46 2010 -0800
+++ b/src/pkg/sync/mutex.go Tue Dec 21 15:12:49 2010 -0800
@@ -59,3 +59,13 @@
    }
    runtime.Semrelease(&m.sema)
 }
+
+// Check if the mutex lock is unlocked.
+// The most common case is where you want to fail code with a high probability
+// if a mutex is not locked. There is no false positive, but there is a
+// false negative if another goroutine is holding the lock.
+func (m *Mutex) IsUnlocked() bool {
+   return m.key == 0
+}
+
+

[adg]

Comment 1:

It seems like a useful debugging tool, but I'm also a little horrified by the idea of
code complex enough to need it. As you observed, the IsUnlocked described here isn't
reliable - an AssertUnlocked that panics if the mutex is locked would be better.

Labels changed: added packagechange.

Owner changed to r...@golang.org.

Status changed to Thinking.

[rsc]

Comment 2:

Should be IsLocked I think, just to avoid double negatives.

Status changed to Accepted.

[gopherbot]

Comment 3 by cw@f00f.org:

Why not an atomic LockIfUnlocked? That's useful sometimes to grab a lock when it's
unlocked and fail otherwise. 
It's also race free. IsLocked for debugging can be done via other means.

[msolo]

Comment 4:

The code that motivated the request was complex and in the end, splitting the lock into
two and making a very clear policy simplified things to the point that I removed this
patch.

[bradfitz]

Comment 5:

I'd like a panicing mutex.AssertLocked() but I'd hate to provide an accessor to allow or
encourage people to do crazy stuff based on the lock status.

[rsc]

Comment 6:

Labels changed: added priority-later.

[rsc]

Comment 7:

I think we can keep trying to avoid this.

Status changed to WontFix.