Hello John, > One of the reasons we maintain multiple queues is because the effects of contention start to become noticeable/significant when this kind of scale is used. <
Noted. In general I would want to use a more sophisticated scheduler than the one we are talking about now. This scheduler is however only going to evaluate the backend on machines with up to 8 cores. > You want to directly insert tasks into the queues without going via async? < By all means, no! Quite the opposite. I noticed, that for just a single call of async my queue backend received multiple insert operations, especially when used on the default pool. From that I concluded, that the thread_data* pushed to the Pending_Queueing queue do not all originate from user-code calls of async (and the like). That means there are thread_data elements that hold _coroutines with parameters that I have no control over. Is that correct? How could I differentiate between thread_data elements created by user-level async calls and thread_data elements created by the system? > Adding an extra async parameter is going to require quite a lot of work to make sure all the overloads do the right thing. < For all intents and purposes the extra parameter can be handled like it was just another parameter to be passed to the action. If need be, I can package all actions to have an additional first parameter, which is not passed on to the packaged action. My problem is: Can I access the parameters of the function represented by a thread_data element via that thread_data element? > Can you describe what the priorities are coming from >that makes you want them so precisely? A good example is our hpx based direct volume rendering compositor. There the volume is split into blocks each of which is represented with an hpx-component. For each, a rendering task is scheduled and the composition is then requested with dataflow in a binary reduction style. For early ray termination, we check after each composition if the image is opaque. Compositions are therefore done in an ordering based on a topological sorting of the rendering results, to ensure that images "in the front" get composited first. However for this approach to make sense we would also want the rendering tasks to be executed according to that sorting (or even better their distance to the camera) so that images "in the front" are also created first. This ordering of rendering tasks could be achieved with a fifo backend by synchronizing the blocks that are colocated and making them issue their render tasks in the correct order. What we were instead doing was creating a user-side priority queue for each locality and everytime a rendering task was supposed to be issued with async we push it to the queue and call async on the first element of the queue instead. However this approach took quite some time to implement (not to be repeated in future projects) and it's not really pretty either. I also suspect it's overhead to be more severe than for a nicely integrated priority queue backend, which is what I want to evaluate, actually. If you have ideas for better solutions, I would be very glad to try them. Best regards, Kilian Werner _______________________________________________ hpx-users mailing list [email protected] https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
