Question

In order to assess whether go is a possible option for an audio/video application, I would like to know whether message passing in go satisfies any non-blocking progress guarantees (being obstruction-free, lock-free or wait-free). In particular, the following scenarios are relevant:

Single producer single consumer:

Two threads communicate using a shared channel. Thread A only does asynchronous sends, thread B only does asynchronous receives. Suppose the OS scheduler decides to interrupt thread A at the “worst possible moment” for an indefinite amount of time. Is thread B guaranteed to finish a receive operation in a bounded number of cpu cycles or is there a (theoretical) possibility that thread A can put the channel into a state where thread B needs to wait for the OS to resume thread A?

Multiple producers:

Several threads A1, A2, A3, … communicate with one or more others threads using a shared channel. The threads Ai only do asynchronous sends. Suppose A2, A3, … are suspended by the OS scheduler at the “worst possible moment” for an indefinite amount of time. Is thread A1 still guaranteed to finish a send operation in a bounded number of cpu cycles? Suppose further that each thread only wants to do one send. If the program is run sufficiently long (with a “malicious” scheduler which potentially starves some threads or interrupts and resumes threads at the “worst possible moment”), is at least one send guaranteed to succeed?

I am not so much interested in typical scenarios here, but rather worst-case guarantees.
See Non-blocking algorithm (Wikipedia) for more details on obstruction-, lock- and wait-free algorithms.

Answer 1

The Go Memory Model doesn’t require sends and receives to be non-blocking, and the current runtime implementation locks the channel for send and recv. This means, for instance, that it is possible to starve a sending or receiving go-routine if the OS-scheduler interrupts another thread running another go-routine which tries to send or receive on the same channel while it has already acquired the channel’s lock.

So the answer is unfortunately no 🙁

_{(unless someone reimplement parts of the runtime using non-blocking algorithms).}