Thanks for all the replies so far. I've come up with something of my own
now. I just like to play with threads a bit and think about solutions.
That's why ;-). All right, here now the "best" solution I have come up with
so far. Any comments greatly appreciated.

The system defines channel objects of which the tasks added to them need to
be executed sequentially. The channels are the building blocks that the
user deals with. The following describes internals to implement sequential
execution of several channels where channels are handled in parallel.

The following queues are defined:

Ready Queue (RQ): Contains all tasks that can be executed immediately by
any thread in the thread pool.

Entry Queue (EQ): Contains all tasks the user wants to be executed as well
as internal admin tasks. The EQ is a priority queue. Admin tasks have
highest priority.

Channels Queues (CQ): For every channel there is an internal channel queue
that is used to preserve the ordering of the tasks inside a channel, e.g.
make sure task are executed sequentially in the order they were added to
the channel (which inserts them into the EQ.

Scheduler: Dedicated thread that takes tasks from EQ. If the task is a user
task it is added to the CQ of the channel the task was added to. If the
head of the CQ equals the just inserted user task it is also added to the
EQ (but remains in the CQ) so that it is executed as soon as the next
thread of the thread pool becomes available.

If a user task has finished execution an internal task TaskFinished is
added to RQ. When executed by the scheduler, the head is taken from the
associated CQ. If the CQ is not empty after the take, the next task is
polled (but not taken) from the CQ and added to the RQ. The TaskFinished
tasks have higher priority than user tasks.

This approach contains in my opinion no logical errors. Note that EQ and RQ
need to be synchronized. I prefer using TransferQueue from JDK8 which is
very fast and where checking for it to be empty or not, polling the head
item is also very fast. The CQs need not be synchronized as they are always
accessed by the Scheduler only.

So far I'm quite happy with this solution. What makes me think is whether
the Scheduler could turn into a bottleneck. If there are much more tasks in
the EQ than it can handle the EQ might grow building up some backlog. Any
opinions about that would be appreciated :-).

Thanks, Haddock

You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts


Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 11 of 11 | next ›
Discussion Overview
groupscala-user @
postedFeb 16, '15 at 4:19p
activeFeb 27, '15 at 9:19a



site design / logo © 2022 Grokbase