|
Legion Runtime
|
#include <mapping.h>
Public Attributes | |
| std::vector< const Task * > | constrained_tasks |
| std::vector< unsigned > | requirement_indexes |
The map_must_epoch mapper call is invoked for mapping groups of tasks which are required to execute concurrently, thereby allowing them to optionally synchronize with each other. Each of the tasks in the 'tasks' vector must be mapped with their resulting mapping being specified in the corresponding location in the 'task_mapping' field. The mapper is provided with the usual inputs for each task in the 'task_inputs' vector. As part of the mapping process, the mapper must abide by the mapping constraints specified in the 'constraints' field which says which logical regions in different tasks must be mapped to the same physical instance. The mapper is also given the mapping tag passed at the callsite in 'mapping_tag'.
A special case of map_must_epoch is when it is called as a collective mapping call for a must epoch launch performed inside of a control replicated parent task. This behavior is controlled by the result of select_sharding_functor for the must epoch operation (see above). In this case map_must_epoch will only be given 'tasks' owned by its shard and 'constraints' that apply to those 'tasks'. The mapper must still pick 'task_processors' and these processor must be unique with respect to any chosen for other 'tasks' by other mappers. The runime will check this property in debug mode. For constraints, the mapper may also pick optional 'constraint_mappings' for its constraints or rely on another mapper to pick them (it's up to the mapper to determine which mapper instance picks thems). The mapper can then specify a 'weight' for each constraint mapping. The runtime will do a collective reduction across all the 'constraint_mappings' taking the mappings with the highest weights and the lowest shard ID when the weights are the same.
1.9.8