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
{{ message }}
This repository has been archived by the owner on Jan 25, 2022. It is now read-only.
(An idea that's been floating around for a while, recorded for posterity, not really urging its adoption yet.)
At present the spec allows futexWait() to throw if an agent does not allow blocking. The normal pattern is that on such a thread, code will probe the shared data structure and if it can't extract a value without blocking it will return to the event loop awaiting a message (after setting a flag to request that such a message is sent). There's an optimization possible here that ties in with the work on synchronics (see Issue #12), namely, that there is no harm if there is an operation to wait actively for a very short time to see if a value is forthcoming; if a value is not then the program would return to the event loop as before. In the situation where there is high-bandwidth communication between workers and the main thread this mechanism can improve performance.
The argument for providing the primitive rather than implementing it in user code is the same as for synchronics: how the micro-waiting is done is highly system-dependent and requires significant programmer sophistication.
The text was updated successfully, but these errors were encountered:
Now that the synchronic proposal has been withdrawn, this idea ties in with the possible need for having some kind of relax/yield/pause mechanism. The latter may be needed to implement efficient locks and condition variables, though that is TBD.
(An idea that's been floating around for a while, recorded for posterity, not really urging its adoption yet.)
At present the spec allows
futexWait()
to throw if an agent does not allow blocking. The normal pattern is that on such a thread, code will probe the shared data structure and if it can't extract a value without blocking it will return to the event loop awaiting a message (after setting a flag to request that such a message is sent). There's an optimization possible here that ties in with the work on synchronics (see Issue #12), namely, that there is no harm if there is an operation to wait actively for a very short time to see if a value is forthcoming; if a value is not then the program would return to the event loop as before. In the situation where there is high-bandwidth communication between workers and the main thread this mechanism can improve performance.The argument for providing the primitive rather than implementing it in user code is the same as for synchronics: how the micro-waiting is done is highly system-dependent and requires significant programmer sophistication.
The text was updated successfully, but these errors were encountered: