I have a large, dynamically-resizable hash table whose access is controlled with a tbb::spin_rw_mutex. Multiple Cilk threads request access to this table, and occasionally one thread's desire to add a new item triggers a resize operation. The thread requesting the resize operation already holds a writer lock, thus the other threads will quickly be blocked from proceding with their read or write requests, and become idle.
The resize operation, which needs to recompute the hash functions for all entries, is easily parallelizable. I expected the runtime system to recognize that the other threads are idle and use them to help with the resize operation. This is not what happens. Using __cilkrts_get_worker_number() I can show that no matter how many times my resize operation spawns child threads to help, all child function calls are being performed by the same thread ID that called the resize operation.
Is Cilk not smart enough to recognize that it can use the idle threads (I've seen that they are idle in VTune Amplifier), or is there some other reason that I cannot resize my hash table in parallel?