I haven't yet seen a harmless data race.

On Friday, February 13, 2015 at 6:20:45 PM UTC+1, Daniel Eloff wrote:

Yes, it should, because it is a race condition, and the race checker can't
know it's harmless in this case. I wouldn't do it unless performance was a
real problem, and I just don't see it being a problem with this code. I'd
stick with the mutex.
On Friday, February 13, 2015 at 10:35:35 AM UTC-5, Marko Tiikkaja wrote:
On 2/13/15 4:25 PM, Daniel Eloff wrote:
On Thursday, February 12, 2015 at 3:48:39 AM UTC-5, ma...@joh.to
You can't look at numOpen without holding db.mu. But the feature
seems useful.
Sure you can. You're not allowed to just read the value, according to Go's
memory model, but you can use sync/atomic to get around that and do a
"racy" read. It's not less correct that the locked approach, since either
way by the time your code uses the returned value you're not holding any
mutex and it can be stale.
OK. But looks like race checker (like you guessed) will complain
*immediately*. So it still doesn't seem like a terribly good idea.

You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 8 of 17 | next ›
Discussion Overview
groupgolang-nuts @
postedFeb 12, '15 at 6:53a
activeFeb 16, '15 at 4:40p



site design / logo © 2022 Grokbase