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
As sketched, the API would allow implementing mutexes and reader/writer locks..
It doesn't support semaphores, where a fixed number of holders can exist simultaneously. (use case: spawning up to N tasks of a given type; further requests must wait until a previous one completes)
We still want to avoid having a separate "register" step prior to the request. We could bolt this on by having a resource become a tuple (name, maxcount), or opening up the mode to be "shared"/"exclusive"/max count. That's still a bit odd since all the cooperators need to agree on what the count is (i.e. each tasks needs to know the global limit, not just some central coordinator)
I think we'd need to work through some examples here, but it at least seems plausible to add on.
The text was updated successfully, but these errors were encountered:
As sketched, the API would allow implementing mutexes and reader/writer locks..
It doesn't support semaphores, where a fixed number of holders can exist simultaneously. (use case: spawning up to N tasks of a given type; further requests must wait until a previous one completes)
We still want to avoid having a separate "register" step prior to the request. We could bolt this on by having a resource become a tuple (name, maxcount), or opening up the mode to be "shared"/"exclusive"/max count. That's still a bit odd since all the cooperators need to agree on what the count is (i.e. each tasks needs to know the global limit, not just some central coordinator)
I think we'd need to work through some examples here, but it at least seems plausible to add on.
The text was updated successfully, but these errors were encountered: