Engine affinity can affect scheduling in process mode

An engine looking for a task to run first looks in its own high-priority run queues, then in the high-priority global run queue. If there are no high-priority tasks, the engine then checks for medium-priority tasks in its own run queue, then in the medium-priority global run queue, and finally for low-priority tasks.

What happens if a task has affinity to a particular engine? Assume that task 7 in Figure 4-2, a high-priority task in the global run queue, has a user-defined execution class with high priority and affinity to engine number 2, but this engine currently has high-priority tasks queued and is running another task.

If engine 1 has no high-priority tasks queued when it finishes processing task 8 in Figure 4-2, it checks the global run queue, but cannot process task 7 due to the engine binding. Engine 1 then checks its own medium-priority queue, and runs task 15. Although a system administrator assigned the preferred execution class EC1, engine affinity temporarily lowered task 7’s execution precedence to below that of a task with EC2.

This effect might be undesirable, or it might be what was intended. You can assign engine affinity and execution classes so that task priority is not what you intended. You can also make assignments so that tasks with low priority might not ever run, or might wait for extremely long times—an important reason to plan and test thoroughly when assigning execution classes and engine affinity.

NoteIn threaded mode, engines and their assigned tasks exist in completely separate search spaces.