search

tc39 / proposal-concurrency-control

interfaces and data structures for concurrency control and integration into async iterator helpers
30 stars 0 forks source link

Naming concerns #4

Open dminor opened 3 months ago

dminor commented 3 months ago

We have some concerns about the use of Governor and Semaphore when we reviewed this proposal.

No one was a big fan of the use of Governor for this, the car metaphor didn't work for us, and we thought that the naming didn't give a good indication of the functionality.

There were also concerns about the use of Semaphore. I would think that the expectation about anything named semaphore is that it would be used to coordinate between multiple threads, but the concurrency control being investigated here actual seems to be single-threaded and between async operations, although to be honest, I'm not entirely sure. It would be great to see this stated explicitly in the explainer.

bakkot commented 3 months ago

I would think that the expectation about anything named semaphore is that it would be used to coordinate between multiple threads, but the concurrency control being investigated here actual seems to be single-threaded and between async operations, although to be honest, I'm not entirely sure. It would be great to see this stated explicitly in the explainer.

Coordination between threads is certainly the textbook example, but controlling access to resources in a concurrent-but-not-parallel system is basically the same problem with the same shape of solution, and people still call it a semaphore in that case. See e.g. various npm packages.

Also per the readme the idea is that these would be shareable across threads (which would require some host integration, and underlying use of atomics), so it would be useful for the classical parallel case as well.

dminor commented 3 months ago

I would think that the expectation about anything named semaphore is that it would be used to coordinate between multiple threads, but the concurrency control being investigated here actual seems to be single-threaded and between async operations, although to be honest, I'm not entirely sure. It would be great to see this stated explicitly in the explainer.

Coordination between threads is certainly the textbook example, but controlling access to resources in a concurrent-but-not-parallel system is basically the same problem with the same shape of solution, and people still call it a semaphore in that case. See e.g. various npm packages.

Ok, it's good to know that there's precedent at least in the JS community for this usage, but I'm still not convinced that's what most people will think of first, e.g. the first sentence of the wiki article says "In computer science, a semaphore is a variable or abstract data type used to control access to a common resource by multiple threads...". I'm not saying we should treat wikipedia as gospel, but I do think it's indicative in this case of what most people's first idea of a semaphore would be.

Also per the readme the idea is that these would be shareable across threads (which would require some host integration, and underlying use of atomics), so it would be useful for the classical parallel case as well.

Thanks! I was able to find this after you mentioned it (using CTRL+F), but it would be great to see this mentioned in the first few paragraphs of the readme. No one picked up on this when we did our internal review of this proposal.