Question: There's no explicit "queue" data structure used in this code, but in class I talked about the code as if there was a work queue, and assignment was performed by idle worker threads pulling the next item to do out of the queue. Why did I describe this code in this way?
kayvonf
Another question: What is the overhead associated with carrying out the dynamic assignment in this program?
abist
I might be wrong but even though there's no explicit queue, the threads are confined by the lock, and thus "wait" until one thread is doing its work. So, the waiting of other threads due to the lock can be thought of as items in a queue.
andrewwuan
I think the overhead is just that the increment of i (retrieving each thread's portion of work) is sequential.
afa4
In this case, whichever thread grabs the lock assigns counter to i, increments counter atomically and then tests primality on the ith element in the array. This is similar to the first in first out behavior of a queue.
I think The overhead is contention for the single shared resource "counter" by all threads.
aznshodan
It would be a queue in a sense that each thread is fetching the first work available(fifo). The overhead would be the time each thread has to wait to access the shared counter and incrementing it.
Question: There's no explicit "queue" data structure used in this code, but in class I talked about the code as if there was a work queue, and assignment was performed by idle worker threads pulling the next item to do out of the queue. Why did I describe this code in this way?
Another question: What is the overhead associated with carrying out the dynamic assignment in this program?
I might be wrong but even though there's no explicit queue, the threads are confined by the lock, and thus "wait" until one thread is doing its work. So, the waiting of other threads due to the lock can be thought of as items in a queue.
I think the overhead is just that the increment of i (retrieving each thread's portion of work) is sequential.
In this case, whichever thread grabs the lock assigns counter to i, increments counter atomically and then tests primality on the ith element in the array. This is similar to the first in first out behavior of a queue.
I think The overhead is contention for the single shared resource "counter" by all threads.
It would be a queue in a sense that each thread is fetching the first work available(fifo). The overhead would be the time each thread has to wait to access the shared counter and incrementing it.