The synchronous scheduling policy seems to imply a sort of barrier-like behavior. All vertex programs in the same “round” must complete, similar to “reaching the barrier”, before they can observe updates from one another.

How would the developer know which scheduling policy and atomicity guarantee to pick for their program when different choices lead to different program correctness/output? Is the choice made programmatically or is it given through some sort of configuration that the developer has to work around/consider as they write their program?

@czh, yes and this is also reminiscent of the algorithms from PA4 where we take steps one by one until we are finished, because we cannot ever have threads working on different steps since steps are dependent on previous ones.

@leo probably trial and error on the part of the developer? If the developer is okay with looser atomicity guarantees because they really want to squeeze out performance and because they can restructure their code to be correct even in the face of weaker guarantees, they might be welcome to do so.

@leo something you could consider is that this higher-level library makes it much easier to iterate on designs of an algorithm. Instead of modifying 70 lines of dense code, you may only need to change 5.