The "granularity" of a task here refers to how many work elements make up a task. In the context of the current programming assignment, we can think of one specific call to a runnable function that does some meaningful work as a "work element" here, which means that the task granularity of a system refers to how many sequential function calls a worker thread does. By increasing the task granularity, we're able to increase the amount of work done by threads relative to the amount of time they spend in critical sections waiting on and using synchronization primitives. However, this also has the potential downside of uneven work distribution, if an unlucky worker thread gets saddled with calculating many long running functions in a row, while the other worker threads exhaust the work queue of other very short-running function calls. Thus, we must balance granularity to achieve an optimal tradeoff between work balancing and critical section overhead (force sequential execution).
The "granularity" of a task here refers to how many work elements make up a task. In the context of the current programming assignment, we can think of one specific call to a runnable function that does some meaningful work as a "work element" here, which means that the task granularity of a system refers to how many sequential function calls a worker thread does. By increasing the task granularity, we're able to increase the amount of work done by threads relative to the amount of time they spend in critical sections waiting on and using synchronization primitives. However, this also has the potential downside of uneven work distribution, if an unlucky worker thread gets saddled with calculating many long running functions in a row, while the other worker threads exhaust the work queue of other very short-running function calls. Thus, we must balance granularity to achieve an optimal tradeoff between work balancing and critical section overhead (force sequential execution).