SingleConsumerUnboundedChannel should allow access to reader count

[Danielku15]

Description

The SingleConsumerUnboundedChannel currently does not allow accessing the item count. This is strange because if you have multiple consumers via UnboundedChannel the access is possible. It feels like a bug to me that you cannot access the count if you have a single consumer but you can if you have multiple ones.

Configuration

.net 5.0.203
Windows 10 Enterprise 2004
x64

Also seems an issue according to the latest source state.

Regression?

From a pure code perspective no. This was never implemented and is sort of a missing feature.

Other information

Code wise it should be fairly easy to add the same count implementation to SingleConsumerUnboundedChannel like in UnboundedChannel .

UnboundedChannel overrides the count and cancount in the reader implementation

runtime/src/libraries/System.Threading.Channels/src/System/Threading/Channels/UnboundedChannel.cs

Lines 57 to 59 in 5dcc340

	public override bool CanCount => true;
	public override int Count => _parent._items.Count;

SingleConsumerUnboundedChannel does not override the members

runtime/src/libraries/System.Threading.Channels/src/System/Threading/Channels/SingleConsumerUnboundedChannel.cs

Lines 60 to 70 in 5dcc340

	{
	_parent = parent;
	_readerSingleton = new AsyncOperation<T>(parent._runContinuationsAsynchronously, pooled: true);
	_waiterSingleton = new AsyncOperation<bool>(parent._runContinuationsAsynchronously, pooled: true);
	}
	public override Task Completion => _parent._completion.Task;
	public override ValueTask<T> ReadAsync(CancellationToken cancellationToken)
	{
	if (cancellationToken.IsCancellationRequested)

But I have to admit that I am not fully aware of potential consequences. There were some concerns by @stephentoub because of the queue not being secured by locks or interlocked operations. The UnboundedChannel uses a Deque which holds the current size as member. So accessing the size is safe. But the SingleConsumerUnboundedChannel uses a SingleProducerConsumerQueue where the count it only internal and requires looping.

From this perspective it might really rather be a feature request than a bug to support the count.

According to the git history the following PR and issue are related to the change adding the count member to UnboundedChannel.
#312
#26706

Tagging subscribers to this area: @carlossanlop
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

The SingleConsumerUnboundedChannel currently does not allow accessing the item count. This is strange because if you have multiple consumers via UnboundedChannel the access is possible. It feels like a bug to me that you cannot access the count if you have a single consumer but you can if you have multiple ones.

Configuration

.net 5.0.203
Windows 10 Enterprise 2004
x64

Also seems an issue according to the latest source state.

Regression?

From a pure code perspective no. This was never implemented and is sort of a missing feature.

Other information

Code wise it should be fairly easy to add the same count implementation to SingleConsumerUnboundedChannel like in UnboundedChannel .

UnboundedChannel overrides the count and cancount in the reader implementation

runtime/src/libraries/System.Threading.Channels/src/System/Threading/Channels/UnboundedChannel.cs

Lines 57 to 59 in 5dcc340

	public override bool CanCount => true;
	public override int Count => _parent._items.Count;

SingleConsumerUnboundedChannel does not override the members

runtime/src/libraries/System.Threading.Channels/src/System/Threading/Channels/SingleConsumerUnboundedChannel.cs

Lines 60 to 70 in 5dcc340

	{
	_parent = parent;
	_readerSingleton = new AsyncOperation<T>(parent._runContinuationsAsynchronously, pooled: true);
	_waiterSingleton = new AsyncOperation<bool>(parent._runContinuationsAsynchronously, pooled: true);
	}
	public override Task Completion => _parent._completion.Task;
	public override ValueTask<T> ReadAsync(CancellationToken cancellationToken)
	{
	if (cancellationToken.IsCancellationRequested)

But I have to admit that I am not fully aware of potential consequences. There were some concerns by @stephentoub because of the queue not being secured by locks or interlocked operations. The UnboundedChannel uses a Deque which holds the current size as member. So accessing the size is safe. But the SingleConsumerUnboundedChannel uses a SingleProducerConsumerQueue where the count it only internal and requires looping.

From this perspective it might really rather be a feature request than a bug to support the count.

According to the git history the following PR and issue are related to the change adding the count member to UnboundedChannel.
#312
#26706

Author:	Danielku15
Assignees:	-
Labels:	area-System.Threading.Channels, untriaged
Milestone:	-

[bollhals]

I just hit this when I was trying to log some information and got a NotSupportedException thrown. Is the current implementation correct or is this bug valid?
(I could throw together a PR fixing this if it is confirmed as a bug)

[stephentoub]

Is the current implementation correct or is this bug valid?

It's correct, because of this:

runtime/src/libraries/Common/src/System/Collections/Concurrent/SingleProducerConsumerQueue.cs

Line 219 in 5dcc340

/// <remarks>This method is not safe to use concurrently with any other members that may mutate the collection.</remarks>

[bollhals]

I checked the code but somehow missed that section. Thanks for linking it!

So based on this, should the issue be closed as working as intended? Or should it be rephrased as a request to make it available?

[stephentoub]

It's fine to leave it open. It's a feature request.
"This was never implemented and is sort of a missing feature."
"From this perspective it might really rather be a feature request than a bug to support the count."