The code in schedule many has been extended by two features:
Both of these lead to some complexity, and the schedule_many code now does a lot of work. It was originally factored into two phases
- acquire phase
- release phase
This effectively replicates the 2PL of enqueue that occurs. However, now in the acquire phase there is a lot of work, and that both complicates the readability, and potentially makes the time taken in the 2PL longer reducing potential throughput.
I propose we split the schedule_many into four phases
- prepare phase - create all the chains that should be added to the DAG, and effectively all calculation that can be done before the first exchange
- acquire phase - Exchange in the set of segments, and track any segments that had no predecessor
- release phase - Mark slots as completed to enable subsequent work to enqueue.
- process phase - Any segments that had no predecessor can be resolved in this phase.
I believe this factoring will help with both readability and performance as it moves work before or after the critical acquire/release phases reducing the time spent blocking other scheduler threads.
I believe this factoring would make it easier to address missing features interaction between the two PRs mentioned above.
@vishalgupta97 @marioskogias as you have both recently touched/reviewed this code. Do you have any thoughts on if this refactoring makes sense to you?
The code in schedule many has been extended by two features:
Both of these lead to some complexity, and the
schedule_manycode now does a lot of work. It was originally factored into two phasesThis effectively replicates the 2PL of enqueue that occurs. However, now in the acquire phase there is a lot of work, and that both complicates the readability, and potentially makes the time taken in the 2PL longer reducing potential throughput.
I propose we split the
schedule_manyinto four phasesI believe this factoring will help with both readability and performance as it moves work before or after the critical acquire/release phases reducing the time spent blocking other scheduler threads.
I believe this factoring would make it easier to address missing features interaction between the two PRs mentioned above.
@vishalgupta97 @marioskogias as you have both recently touched/reviewed this code. Do you have any thoughts on if this refactoring makes sense to you?