Semaphores act as FIFOs -- is this behavior protected from future changes?

[waynr (wayne)]

So the question of whether we can use semaphores as an implementation detail of a kind of unbounded FIFO queue mechanism for an arbitrary number of goroutines came up with a colleague earlier today. My colleague pointed out that we couldn’t rely on FIFO behavior with semaphores since it’s neither implied by the API semantics nor is it documented at the package level. In fact, he was assuming that it isn’t a FIFO whereas I assumed that it is.

When I dug down into the implementation, I found that it is:

• Weighted.Acquire pushes an empty “waiter” channel to the back of a list.List
  • https://cs.opensource.google/go/x/sync/+/0de741cf:semaphore/semaphore.go;l=57
• Weighted.notifyWaiters takes items from the front of the list.List whenever any given holder releases the semaphore:
  • https://cs.opensource.google/go/x/sync/+/0de741cf:semaphore/semaphore.go;l=111

So my question – is FIFO behavior simply an accident of implementation here, or is it intended and protected from backwards-incompatible changes in the future?

If it’s intentional, would it make sense to document at the package level to clarify?

Thanks in advance to anyone who can take the time to clarify this!

[skillian (Sean Killian)]

If it’s not documented, you can’t depend on that behavior. The Go team could change it at any time and if you were to open an issue, they would likely say that the behavior was never guaranteed. That decision would probably only be overturned if a lot of people were using it that way.

If I understand you correctly, it sounds like you’re essentially looking for a channel with unbounded capacity. If that’s right, you could always use a goroutine with a slice! Go Playground - The Go Programming Language