The idea is to decrease concurrent access to the resource-user-lists when creating new tasks.
Most likely, the application developer will create patterns of resource-usage. For tasks that use common resources, they will probably be passed to emplace_task in the same or similar order.
Since currently the ordering of Resource-accesses directly translates to the list of unique-resources that will be considered during graph-creation, init_graph() will check them in the order as specified in the task-arguments. Since tasks may be initalized in parallel by different workers, both workers would try to access the resource-user-lists in the same order, which might lead to high rate of cache invalidation if they run with minimal delay between each other. A randomized access order might mitigate potential latencies from invalidation by averaging out the probability of shared access.
The idea is to decrease concurrent access to the resource-user-lists when creating new tasks.
Most likely, the application developer will create patterns of resource-usage. For tasks that use common resources, they will probably be passed to
emplace_taskin the same or similar order.Since currently the ordering of Resource-accesses directly translates to the list of unique-resources that will be considered during graph-creation,
init_graph()will check them in the order as specified in the task-arguments. Since tasks may be initalized in parallel by different workers, both workers would try to access the resource-user-lists in the same order, which might lead to high rate of cache invalidation if they run with minimal delay between each other. A randomized access order might mitigate potential latencies from invalidation by averaging out the probability of shared access.