Code is at https://go-review.googlesource.com/c/go/+/88957

What are the practical uses of this feature along with the benchmarks compared to the existing implementation as well as atomic load/copy/swap?

A practical usage example is given in the proposal.

The cost of DowngradeLock() is strictly less than a "Unlock(); RLock()"
pair, as the implementation of DowngradeLock() is essentially the same as that
of Unlock() but with different constants.

Benchmark:

type PaddedRWMutex struct {
    RWMutex
    pad [32]uint32
}

func BenchmarkRWMutexNonAtomicDowngradeUncontended(b *testing.B) {
    b.RunParallel(func(pb *testing.PB) {
        var rwm PaddedRWMutex
        for pb.Next() {
            rwm.Lock()
            rwm.Unlock()
            rwm.RLock()
            rwm.RUnlock()
        }
    })
}

func BenchmarkRWMutexAtomicDowngradeUncontended(b *testing.B) {
    b.RunParallel(func(pb *testing.PB) {
        var rwm PaddedRWMutex
        for pb.Next() {
            rwm.Lock()
            rwm.DowngradeLock()
            rwm.RUnlock()
        }
    })
}

Result:

BenchmarkRWMutexNonAtomicDowngradeUncontended-12    	200000000	         6.65 ns/op
BenchmarkRWMutexAtomicDowngradeUncontended-12       	300000000	         5.61 ns/op

We can protect the consistency from panic by "Lock(); defer Unlock(); doPanicThing()". Is there a way to do so when it comes to …

Lock()
doPanicThing() // not safe
DowngradeLock()
defer RUnlock ()
doReadPanicThing() // this line is panic-safe

I'm not convinced this is helpful in a real program, and there is a real cost to adding complexity to the API. Please show us benchmarks improving a real workload, not a microbenchmark.

To use defer, one would have to introduce a variable to track the lock state:

rw.Lock()
var readLocked bool
defer func() {
  if readLocked {
    rw.RUnlock()
  } else {
    rw.Unlock()
  }
}()
doPanicThing()
rw.DowngradeLock()
readLocked = true
doReadPanicThing()

But I think using Unlock(); RLock() has the same requirement.

@rsc: I do have benchmarks that show a measurable improvement in a critical hot path of my application, but I can't share them publicly. I've contacted you privately.

To use defer, one would have to introduce a variable to track the lock state

Sounds like a major disadvantage, it would be another shiny feature that's easy to misuse. Without an actual benchmark, it's not easy to see the advantage. If a clear example isn't trivial to write, maybe that's a further argument for the feature's unwarranted complexity.

Note that you can substitute a custom RWMutex implementation into your own code (copy and modify). We don't want to add the complexity here - and support it forever - especially with such an awkward API.