Kor

Have a look at limiting_executor in the source (1.5 release only). It is a 
replacement in some ways for the sliding_semaphore


The caveat is that the user must launch the work/tasks using the limiting 
executor - if you want to allow the user to launch work using another executor, 
but have it still capped/limited, then I'd need to extend this somehow. There 
is an example in the async_mpi module that uses the number of mpi tasks in 
flight to cap the task count, but it hooks into the executor using a special 
customization - it might give you ideas.


I'd be happy to chat about it if you have a specific use case and want to zoom 
call me sometime.


JB



--
Dr. John Biddiscombe,                    email:biddisco @.at.@ cscs.ch
http://www.cscs.ch/
CSCS, Swiss National Supercomputing Centre  | Tel:  +41 (91) 610.82.07
Via Trevano 131, 6900 Lugano, Switzerland   | Fax:  +41 (91) 610.82.82
________________________________
From: [email protected] <[email protected]> 
on behalf of Kor de Jong <[email protected]>
Sent: 02 September 2020 10:57:17
To: [email protected]
Subject: [hpx-users] Limiting the speed with which tasks are created

Hi list,

I have a question about limiting the speed with which tasks are created:

What are the options to limit the speed with which tasks are generated,
without having access to futures representing one or more task trees?

I develop a set of algorithms that create tasks. Other people will be
using these algorithms. Ideally, I would like to also offer a hook to
set a maximum tree depth. But, ideally, I have no information about the
task trees created by the user's code. I do not have access to the
futures representing these.

I currently use a sliding semaphore in combination with a (too) special
future representing a user's task tree. This works, but is not flexible
enough. It cannot handle the situation of having multiple task trees,
for example. Also, the user now needs to decide on which future is the
root of the task tree. I would prefer the user to only have to think
about which algorithms to call and not about task trees and dependencies
between tasks.

I offer the user a framework to simulate processes iteratively through
time using time steps. My algorithms are intended to be called per time
step. The maximum tree depth in my use case is typically expressed as
the maximum number of time steps for which task are created. The
iteration through time is part of my library code. I know nothing about
which of the algorithms are actually called and in which order.

I can imagine that what I need is not possible / very hard to achieve,
but maybe I am wrong?

Thanks in advance for any hints!

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

Reply via email to