sync: RWMutex can deadlock when readers queue behind a writer #5692

Activity

1. deadprogram commented on Sep 19, 2026

   

   deadprogram

   on Sep 19, 2026

   Member

   More actions

   What was the original problem in one of your projects that triggered this @yohimik ? Perhaps a single simple reproducer, if you please?
2. yohimik commented on Sep 20, 2026

   

   yohimik

   on Sep 20, 2026

   ContributorAuthor

   More actions

   @deadprogram The original failure was in CLI tests that created processes and pipes at the same time. The tests stopped making progress. The shared lock was syscall.ForkLock, which uses sync.RWMutex.

   Here is a small standalone version of TestRWMutexWriterNotStarvedByLateReaders. It removes the process and pipe code and keeps the lock sequence that caused the failure:

   package main
   
   import (
   	"fmt"
   	"sync"
   	"time"
   )
   
   func main() {
   	var mu sync.RWMutex
   	writerDone := make(chan struct{})
   	readerDone := make(chan struct{})
   
   	mu.RLock()
   	go func() {
   		mu.Lock()
   		mu.Unlock()
   		close(writerDone)
   	}()
   	time.Sleep(50 * time.Millisecond)
   
   	go func() {
   		mu.RLock()
   		mu.RUnlock()
   		close(readerDone)
   	}()
   	time.Sleep(50 * time.Millisecond)
   	mu.RUnlock()
   
   	select {
   	case <-writerDone:
   	case <-time.After(10 * time.Second):
   		panic("writer did not finish after the first reader unlocked")
   	}
   	select {
   	case <-readerDone:
   	case <-time.After(10 * time.Second):
   		panic("queued reader did not finish")
   	}
   	fmt.Println("ok")
   }

   Save this as main.go and run tinygo run main.go. The expected result is ok. The sleeps give the writer and second reader time to enter their lock calls, so this reproducer depends on scheduling.

   In the affected implementation, the second reader increases the reader count before it waits for the writer. When the first reader unlocks, the count still includes that waiting reader. This prevents the writer wakeup. The writer and second reader then wait for each other.

   The regression test reproduced the failure with TinyGo v0.42.0 on Linux/arm64 and Darwin/arm64 on 2 September, as recorded above. I have not rerun this standalone version. The same test is included in #5697.
3. deadprogram commented on Sep 22, 2026

   

   deadprogram

   on Sep 22, 2026

   Member

   More actions

   Handled in #5697 labeling to close on next release.
4. deadprogram

   added

   next-releaseWill be part of next releaseWill be part of next release

   on Sep 22, 2026
5. Elojah

   added a commit that references this issue on Oct 5, 2026

   ci: TinyGo

   ...

   b8fa9a9
6. deadprogram

   removed

   next-releaseWill be part of next releaseWill be part of next release

   on Oct 10, 2026
7. deadprogram

   closed this as completedon Oct 10, 2026