I wonder how you would decide on the time constant for changing static assignments, given the tradeoff that exists between even workload for frequently updated assignments and overhead for frequent updates.

It seems like the premise here is somewhat similar to distributing larger chunks of tasks. We can view a windowed static assignment as breaking the tasks into larger chunks which may potentially be uneven but still produce speedup because of less synchronization that offsets lack of granularity. The difference here is the assignment chunks are in a temporal domain (as opposed to say with sorting, saying sort X subsection of the array which may already be in order and cheap or something). I wonder if there are any proofs or nice formulas that can give good arguments for when such a technique may actually provide benefit. I suppose one can just calculate overhead of sync + granularity benefit...

Does the "semi-static" assignment requires that re-adjustment should also follow some "static" assignment rule?

@zecheng I think the assignment rules could be pre-defined, or they could also be based on "recent past" as the slide suggests.

@zecheng, in my mind when I think of "semi-static" I akin it to making an educated guess about the work load. So in the event that we are pretty sure (something like with high probability) an event is going to take a computational resources then we can have multiple threads handle it. On the other hand for tasks that we think have a lower probability of taking a lot of time to compute, we can have just one thread handle it.

A little confused about the boundary between "semi-static" and "dynamic": does "semi-static" have to decide some rule at the beginning and go through some adjustment?