Is there a simple way to resurrect UnbufferedChannels?

[jcoo092]

Hi lovely .NET team,

System.Threading.Channels has Bounded and Unbounded variants. It turns, though, that back in the day there was also an Unbuffered variant, as described in e.g. this old README. It appears that they were removed a bit later on, documented in this issue.

For what I am working on at the moment, however, the UnbufferedChannel is the best fit for what I modelling (long story - basically, it'd be ideal if both the sender and receiver synchronise on the exchange). Is there some reasonably simple approach I could take to bring back UnbufferedChannels specifically for what I'm working on? The only likely possibility I can think of is including a version of the System.Threading.Channels namespace with the UnbufferedChannel parts as a project in my overall Solution. I suspect that after this much, time, however, that'll probably not be a trivial task (if it even could work).

(If you're wondering, using BoundedChannel with capacity 1 does work reasonably well, but in my particular circumstance an UnbufferedChannel is preferable)

Thanks for your time.

[stephentoub]

Hi. You could copy out the old code and try to fix it up to meet your needs (the relevant APIs are virtual to enable creating custom channels), but some aspects of the model don't fit well with the concept, which is one of the reasons it was removed. For example, if a writer is only ever using TryWrite and a reader is only ever using TryRead, given the synchronization required they'll never show up as being there at the same time and thus will never successfully rendezvous. Similarly, if for example a reader was in a loop that did WaitToReadAsync and then a TryRead, it will similarly only work if a writer did a write with WriteAsync; if the writer only ever wrote with TryWrite, they wouldn't successfully rendezvous.

[jcoo092]

Thanks for your quick response! I'll have to take a look at the APIs you mention, though I'm guessing I probably will just continue to use the BoundedChannel in the end.

You make a good point on the risks with UnbufferedChannels. In my particular circumstance, only AsyncWrite and AsyncRead are used - at the point of communication, both senders and receivers will have nothing else they can do and so should block until after completing a message exchange. Thus TryRead and TryWrite aren't used.

[shartley-qontigo]

I found this discussion as I had come to ask why Bounded Channels required a minimum capacity of 1, and didn't allow 0, noting that the 0 case would likely require a special implementation - UnbufferedChannel being the answer.

Looks like I'll pull out the UnbufferedChannel code for my own purposes, noting the gotchas above. @stephentoub are there any recommended alternatives though? Of course I could wire up my own solution, but there's a certain simplicity to the Channel API (or at least the subset of it that is safe to use in this Unbuffered mode) that makes it attractive to use here. Reading #24831, it seems there was no internal need for this, but I'll throw my vote behind it in case you are thinking of re-introducing it.

My use-case is single producer and consumer, where I want the writer to abort sending the message if it is not read out of the channel by the consumer within a certain time (and not simply accepted into the channel within the timeout which the cancellationToken on WriteAsync supports). Having a buffer of even one item doesn't work so well here, as once the item has been accepted into the channel I can't cancel it. The item could be sat in that buffer for an indeterminate amount of time without my producer being able to take its abortive measures.

But with an unbuffered Channel, I can WriteAsync with a cancellation token that fires when my timeout is hit. If WriteAsync succeeds, I know it was accepted by the Reader within my time window, and not just accepted into the buffer.

Conceptually, are channels a good fit here or have I been staring at them too long such that all problems look like a Channel?

I think I can probably code up an alternative to UnbufferedChannel by using a bounded capacity of 1, and making use of TryPeek() on the consumer to process the item and only Read it when my consumer has finished processing it, allowing a new one to pushed at this point. This does seem quite limited though as it could only support a single consumer (fine for my current case, but maybe not in the future).

As a final alternative I can probably go the route of something entirely home made, using something like reset events, but I'd rather see if there is prior art here and walk the path already taken.

[stephentoub]

Conceptually, are channels a good fit here or have I been staring at them too long such that all problems look like a Channel?

You could use it for that, you'll likely just need to be selective in which APIs are used, and more specifically the combination of which are used, as I noted in my previous reply. If you control the producers, for example, and can ensure they always write with WriteAsync rather than ever using TryWrite, any API a consumer chose should work fine.