Hey Werner,

> in our current HPX driven project, we encountered the need
> for a functionality, of which we are unsure if it
> currently exists in HPX:
> 
> We picture in an abstract way the HPX runtime to behave
> like the following:
> Whenever a task is scheduled on a locality (with e.g.
> async) this task is pushed into a FIFO-Queue and whenever
> resources for computation become available the queue is
> polled.
> 
> However we would need a functionality to modify the order
> of execution of already scheduled tasks, e.g. replace this
> (imaginary, behind-the-scenes) FIFO-Queue with a
> Priority-Queue.
> 
> In other words:
> Our program schedules a lot of tasks locally and continues
> to schedule more and more batches of tasks locally over
> time. However we would like tasks that are scheduled at a
> later point in time to possible be run before
> not-yet-started tasks that were scheduled earlier on. For
> this, in our application each task can be assigned a
> unique priority which is calculatable from the arguments
> passed to the asynchronously called function.
> 
> Consider the following explanatory code:
> 
> for (int i = 0; (i < n); i++)
>      hpx::async<some_action>(float priority, T
> other_parameters);
> 
> This code snippet would be called multiple times on the
> same locality scheduling multiple batches of tasks of type
> some_action. We now want all tasks of type some_action on
> a certain locality to be executed in an order where the
> priority is considered.
> 
> Note that it is no problem to run tasks with a lower
> priority before other tasks with a higher priority, if
> these higher priority tasks just was not scheduled for now
> (think Priority-Queue functionality).
> 
> Is there a way to intervene with the hpx runtime on such a
> low level?
> 
> Thanks in advance,
> 
> Kilian Werner
> 
> P.S.: The problem could also be solved by scheduling the
> tasks of type some_action with an executor, which
> internally forwards the tasks through a priority-queue
> based semaphore, but it would be hard to allow just enough
> tasks through the semaphore to fill all computational
> resources.

I see two possible solutions, one easy one (which is not perfect), and a
real solution (requiring more work):

Easy solution: the main scheduler in HPX currently supports 3 priorities:
low, normal, high. We use the high priority for important system tasks
(timers, etc.) mainly. The logic the scheduler uses is very simple, always
first drain the high priority tasks before even looking whether there is
work with lower priority available. That means that high priority tasks
should be used carefully to avoid stalling the normal work. You could use
this mechanism if you have single tasks which are very important to run
first. There is an example in the repo showing how it's done here:
https://github.com/STEllAR-GROUP/hpx/blob/master/examples/quickstart/customi
ze_async.cpp. However, as said, be careful not to stall everything else.

Difficult solution: add a priority queue scheduler to HPX and use it. I'd be
happy to help here, but that's nothing one could do in a day or so.
Essentially, the schedulers we have currently all rely on the same queue
implementation (here:
https://github.com/STEllAR-GROUP/hpx/blob/master/hpx/runtime/threads/policie
s/lockfree_queue_backends.hpp). The scheduler receives the concrete queue
type to use as a template parameter (for instance here:
https://github.com/STEllAR-GROUP/hpx/blob/master/hpx/runtime/threads/policie
s/local_priority_queue_scheduler.hpp#L59).

As you can see the queue-backends currently don't even receive a task
priority. That's because we maintain several queues, one for each priority.
 
What I could offer is to help integrating a (thread-safe, high-performance)
priority queue implementation you would have to provide with the rest of
HPX. 

Overall, we'd be more than happy to improve the capabilities of the HPX
schedulers, so this is definitely something we would support to the broadest
extent possible.

HTH
Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu



_______________________________________________
hpx-users mailing list
[email protected]
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Reply via email to