runtime: don't send preemption signal if there is a signal pending

If multiple threads call preemptone to preempt the same M, it may
send many signals to the same M such that it hardly make
progress, causing live-lock problem. Only send a signal if there
isn't already one pending.

Fixes #37741.

Change-Id: Id94adb0b95acbd18b23abe637a8dcd81ab41b452
Reviewed-on: https://go-review.googlesource.com/c/go/+/223737
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

src/runtime/runtime2.go

@@ -539,6 +539,10 @@ type m struct {
 	// requested, but fails. Accessed atomically.
 	preemptGen uint32
 
+	// Whether this is a pending preemption signal on this M.
+	// Accessed atomically.
+	signalPending uint32
+
 	dlogPerM
 
 	mOS

src/runtime/signal_unix.go

@@ -333,6 +333,7 @@ func doSigPreempt(gp *g, ctxt *sigctxt) {
 
 	// Acknowledge the preemption.
 	atomic.Xadd(&gp.m.preemptGen, 1)
+	atomic.Store(&gp.m.signalPending, 0)
 }
 
 const preemptMSupported = pushCallSupported
@@ -359,7 +360,14 @@ func preemptM(mp *m) {
 		// required).
 		return
 	}
+	if atomic.Cas(&mp.signalPending, 0, 1) {
+		// If multiple threads are preempting the same M, it may send many
+		// signals to the same M such that it hardly make progress, causing
+		// live-lock problem. Apparently this could happen on darwin. See
+		// issue #37741.
+		// Only send a signal if there isn't already one pending.
 		signalM(mp, sigPreempt)
+	}
 }
 
 // sigFetchG fetches the value of G safely when running in a signal handler.