Fix CountdownEvent.Wait to respect underlying event's status (dotnet/corefx#35024)
authorStephen Toub <stoub@microsoft.com>
Wed, 6 Feb 2019 14:55:45 +0000 (09:55 -0500)
committerGitHub <noreply@github.com>
Wed, 6 Feb 2019 14:55:45 +0000 (09:55 -0500)
commit9b274ecdfd499dfacfcd8185ad417ad1ee7cccf4
tree2d0dd1ade39e65c63d6ff1a45439a93b9d9a237e
parent75920800c68b163bf8abe36fc3c877b2ae9b182b
Fix CountdownEvent.Wait to respect underlying event's status (dotnet/corefx#35024)

A common pattern with CountdownEvent is:
```C#
ce.Reset(count);
.. // launch count operations that'll all call ce.Signal()
ce.Wait();
```
and to use that repeatedly.  Reset is explicitly not a thread-safe operation, but in a pattern like this, it should be acceptable as long as the only operations signaling the event are those launched here, since Wait should only return when they've all completed.  However, CountdownEvent.Wait is currently checking CountdownEvent.IsSet, which returns true if the count has reached 0, and the CountdownEvent.Signal method first decrements the count and the sets the underlying event if it reaches 0.  That means there's a window where the count is 0 but the event hasn't been set, which means if Wait is called in that window, it could return successfully even though an operation is still in flight invoking Signal, which then in turn is problematic as that could race with a subsequent call to Reset.

This fixes that by checking this._event.IsSet instead of this.IsSet.

Commit migrated from https://github.com/dotnet/corefx/commit/66403fb0e4c9e3c05e23db23c04742b8a50dbe0a
src/libraries/System.Threading/src/System/Threading/CountdownEvent.cs