You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
is it possible for the receiver thread hanging forever?
my reasoning
For is_ready, the sender thread stores true with Release ordering and then unpark the Receiver thread.
After woken up, the receiver thread will check the is_ready again. However, it's possible that the return value is still false because we are using simple load.
This will park the receiver thread again and no other events will wake it up, thus hanging forever.
The text was updated successfully, but these errors were encountered:
The answer is, fortunately: no, this won't hang forever. However, the reason for that is subtle and not actually fully explained in the book. (I might go a bit deeper into that in a next edition of the book.)
The reason this won't hang forever, is that unpark() forms a happens-before relationship with the park() call that it wakes up. (See the comment in the implementation here.)
I'll see if we can document that better and make it a proper guarantee.
The content that the question is about
In Chapter 5. Building Our Own Channels
the implementation is from Safety Through Runtime Checks
The question
is it possible for the receiver thread hanging forever?
my reasoning
For
is_ready
, the sender thread storestrue
withRelease
ordering and then unpark theReceiver
thread.After woken up, the receiver thread will check the
is_ready
again. However, it's possible that the return value is stillfalse
because we are using simpleload
.This will park the receiver thread again and no other events will wake it up, thus hanging forever.
The text was updated successfully, but these errors were encountered: