Add new ChannelTaskScheduler Extension

[Zetanova]

As requested inlining https://github.com/Zetanova/Akka.Experimental.ChannelTaskScheduler into akka and using it as the default
channel-executor

usage like before, the channel-executor.priority config value is already set in the default config.

to activate use:

akka.actor.default-dispatcher = {
    executor = "channel-executor"
    #channel-executor.priority = "normal"
}

akka.actor.internal-dispatcher = {
    executor = "channel-executor"
    #channel-executor.priority = "high"
}

akka.remote.default-remote-dispatcher {
    executor = "channel-executor"
    #channel-executor.priority = "high"
}

akka.remote.backoff-remote-dispatcher {
    executor = "channel-executor"
    #channel-executor.priority = "low"
}

All akka components can thread-safe access the priority TaskSchedulers over:

ChannelTaskScheduler.Get(system).High
ChannelTaskScheduler.Get(system).Normal
ChannelTaskScheduler.Get(system).Low
ChannelTaskScheduler.Get(system).Idle

[Aaronontheweb]

The code looks fine - I think we also need to add:

• Some configuration specs, validating that default values can be successfully changed via HOCON
• Some documentation additions to https://getakka.net/articles/actors/dispatchers.html explaining how to configure this and when you might want to use it
• Address some of my inline comments, which ask for more clarification on the internals so other contributors / maintainers can reason about the algorithm.

[Zetanova]

I added the comments and rollback dependency to 5.0.0

[Zetanova]

About the https://getakka.net/articles/actors/dispatchers.html where to edit it, can u do it?
The only thing that changed between the last channel-executor and this,
is the channel-executor.priority config instead of the max-concurrency calculated from fork-join-executor settings

[Aaronontheweb]

I’ll reply with a link to the .MD file once I’m back at my desk. On mobile at the moment.

…

Sent from my iPhone

On Dec 3, 2021, at 8:11 AM, Andreas Dirnberger ***@***.***> wrote:  About the https://getakka.net/articles/actors/dispatchers.html where to edit it, can u do it? The only thing that changed between the last channel-executor and this, is the channel-executor.priority config instead of the max-concurrency calculated from fork-join-executor settings — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub, or unsubscribe.

[Aaronontheweb]

About the https://getakka.net/articles/actors/dispatchers.html where to edit it, can u do it?

Yep, I can do it.

[Aaronontheweb]

LGTM

[to11mtm]

Would there be any benefit to just using a minimal abstraction over ConcurrentQueue<Task> for the common case of multiple readers (where an UnboundedChannel would be created)?

I mention this because UnboundedChannel.TryWrite involves a lock on a parent SyncObject, which is primarily used for waiting completions and async readers. This will likely impact max throughput. We do use the Async Completions in the control section but I wonder if there is a way we can work around that too?

[Zetanova]

Good point, I will take a look the the Channel source code too.

In the end the queue should lock-free queued and dequeued,
where adding side should have the heavier processing (splitting in priorities)

[Zetanova]

I looked up and yes there is a brief lock.

The lock will not have much perf. issue on the executing thread itself,
but of course on locking threads. Don't know why it is not implemented in a free-lock style.
Maybe the lock collation just don't happen that often to take it into effect?
I trust "stephentoub" in his decision to use a lock here.

The lock statement is on itself is not "bad" but misused it can be very fast.

The main benefit of the Channel class is following line, it is reducing the idle cpu to near zero:
https://github.com/dotnet/runtime/blob/386f87139c7fe48f6b733e3cae6d09128c827192/src/libraries/System.Threading.Channels/src/System/Threading/Channels/UnboundedChannel.cs#L295

[Zetanova]

I rechecked now the UnboundedChannel.TryWrite code

1. it would be absolutely hard not to use a sync lock
2. Collisions are very unlikely, even under heavy queue load