Skip to content
This repository has been archived by the owner on Jan 25, 2022. It is now read-only.

Design: micro-wait on the main thread? #64

Open
lars-t-hansen opened this issue Feb 25, 2016 · 1 comment
Open

Design: micro-wait on the main thread? #64

lars-t-hansen opened this issue Feb 25, 2016 · 1 comment

Comments

@lars-t-hansen
Copy link
Collaborator

(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.

@lars-t-hansen
Copy link
Collaborator Author

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant