4 ms·
You're still shaving v here, we can just see from the snipped that the shared v isn't used inside the anon function. But I suspect what the GP meant by "easy"
by flyinRyan 13y ago
You're still shaving v here, we can just see from the snipped that the shared v isn't used inside the anon function. But I suspect what the GP meant by "easy" is not having to think about this sort of thing. Your solution is good when you know you need to do this, but it can't even happen in Erlang so it's not a "gotcha" to watch out for.
- Jabbles 13y agoSharing v isn't the problem. The problem occurs when v is evaluated. The parent's post has no race condition, as v is evaluated before the goroutine starts. The top example of my post has a race condition because there is no guarantee when v will be evaluated wrt to the loop. The bottom example has no race condition because v is evaluated on every iteration and assigned to s, which is used by the goroutine at some point afterwards.
- flyinRyan 13y agoMy point still stands: to fix this, you have to realize that (a) v could be shared here and (b) that sharing could be a problem. I suspect the first time most newbies get hit with a race condition here they're going to be beyond baffled.