I think you're making this harder than it is.
-
You want to limit the number of work items in progress at one time, so you will need a queue of pending work items.
-
Since concurrency is involved, you'll need an actor to maintain the queue safely.
-
When a work item arrives (or is created, or whatever), it's given to the actor which decides whether to queue it or start a task for it.
-
When a task finishes, it notifies the actor, which can decide whether to start another task for a new work item.
There's no particular reason for these tasks to loop or perform multiple work items. That's an artifact of a thread-based design, where you care about keeping existing threads around. Tasks are lighter-weight than threads, so (except in unusual cases) you can just create them on demand.
Note that the number of tasks doesn't tell you the number of concurrent operations. The "amount" of concurrency available depends on the system and what else it is doing.
The implementation here involves a count and an array (or other queue structure). That's about it.