Naming concerns

[dminor]

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]

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]

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.

[michaelficarra]

Even though I think Semaphore was an entirely appropriate name, I'd actually prefer we stick with the new name CountingGovernor as I expect we'll want to have other kinds of built-in governors eventually, and it would be nice to give them similar names (IntervalGovernor, PriorityGovernor, RampUpGovernor, etc).

As for Governor, until I've heard a better suggestion, I'm going to keep it as-is. I actually really, really like this name. The Wikipedia article shows that it is used in many analogous mechanical contexts. The only other name I've been able to think of that comes close is Regulator, but I think that comes with much more baggage.