tree 1d853ff1da5fb975241356181d730e5e5371c4ac
parent 6d3f0bb11be5e03f8353894b7240e7d793e40a8f
author Ziheng Liu <lzhfromustc@gmail.com> 1571859096 +0000
committer Sameer Ajmani <sameer@golang.org> 1571878454 +0000

Add critical section to protect lim.limit

***Description***
Among 9 usages of lim.limit , 8 of them are protected by `lim.mu.Lock()`, but the one at line 226 is not protected. So I add a critical section to protect the read operation.

Among 8 usages of lim.limit that are protected, there are 2 usages at line 350 and 357 in function `lim.advance()`. They may seem to be unprotected at first glance, since `lim.mu.Lock()` doesn't appear in `lim.advance()`, but actually all three usages of `lim.advance()` are in critical section.

***How to trigger this bug***
I found this bug occasionally by my static checker, so I can only come up with a hypothesis to trigger it:

If one goroutine is calling `rate.WaitN()` and another goroutine is calling `rate.SetLimitAt()`, then the read operation in `rate.WaitN()` and the write operation in `rate.SetLimitAt()` will race.

***About my patch***
There are several ways to fix this bug, and I chose an efficient but not elegant one. Please let me know if you think other ways are better.

Change-Id: I229bc06a2caa483b9dfb0f4e682cfc144c5aa07c
GitHub-Last-Rev: 192792cf2c5d0d3e8d1ac1345ead38f6ab3c46bc
GitHub-Pull-Request: golang/time#7
Reviewed-on: https://go-review.googlesource.com/c/time/+/188898
Reviewed-by: Sameer Ajmani <sameer@golang.org>