[channel] Fix race condition on channel.Ready.Reset()

[liran-funaro]

Type of change

• Bug fix

Description

Root cause: The Ready.Reset() method was experiencing a race condition due to non-atomic struct field replacement. The original implementation used *r = *NewReady() to reset the struct, which performs a multi-step memory copy operation that replaces all fields (channels ready, closed, and once). This struct copy is not atomic.

Concurrently, other goroutines calling WaitForReady() or WaitForAllReady() would read from the same channel fields (r.ready and r.closed) via select statements. This created a classic data race where one goroutine was writing to struct fields while others were simultaneously reading from them.

Race scenario:

1. Goroutine A calls Reset() and begins copying new struct fields (non-atomic multi-step operation)
2. Goroutine B calls WaitForReady() and attempts to read r.ready or r.closed channels
3. Data race occurs: Goroutine A writes to memory while Goroutine B reads from the same memory locations

The fix: Uses atomic pointer indirection by moving channels into an inner ready struct and storing only an atomic.Pointer[ready] in the outer Ready struct. This enables atomic swapping of the entire internal state via CompareAndSwap(), eliminating the race condition while maintaining the same external API.

Related issues

• discovered by [CI] Enable race detection for unit tests in CI #442

[cendhu]

Please add root cause in all PR description to save review time.

[cendhu]

An example #410

It was generated by Bob.

[coveralls]

coverage: 90.387% (+0.1%) from 90.284%
when pulling b1a49aa on liran-funaro:channel-race
into 355e2a9 on hyperledger:main.

[liran-funaro]

Please add root cause in all PR description to save review time.

@cendhu done

[cendhu]

LGTM