On Thu, Apr 12, 2018 at 11:09 PM, Penguin Enormous
<kimkhanh...@gmail.com> wrote:
> Hi Gophers!
> I'm trying to understand line 522 of src/runtime/sema.go:
>> if atomic.Load(&l.wait) == atomic.Load(&l.notify) {
>> ...
> I can't help but thinking, what guarantee that the atomic read of l.wait
> won't return stale value, making the signaler abandons their current
> signaling attempt, leaving current waiters to be blocked forever if the same
> signaler won't return again or there's no other signaler in the future at
> all?
> I think I'm missing something crucial here because I am perfectly aware that
> reasoning about synchronization is hard, especially for someone in the
> process of learning like me. Could someone point that out to me?

Stale how?  An atomic.Load should always see the result of the most
recent atomic operation on the  address.  There are certainly race
conditions here, but that is OK--this code is only used for condition
variables, and to avoid races on condition variables you must acquire
the lock before calling Signal or Broadcast.

Can you explain more clearly the problem you see?  For example, sketch
out the sequence of calls might be each goroutine.


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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to