Another simple way to do it is to maintain a global variable which is incremented each time the configuration changes.   Each time the threads wake up, they notice if the value of that variable has changed since the last time they looked at it.   If so, they replace their configuration data before handling the next request.

Use a “write once, read many” semaphore arrangement so that the thread which wants to replace the configuration data can’t do so if anyone is reading it at the time ... but you don’t care how many threads might be reading it at the time.

By the way, you can use the same locking semantics to maintain just one configuration-data structure, at the slight expense of lock-management overhead.   Threads use a semaphore to maintain read-stability of the data structure while they are referring to it, but without blocking any other readers.   They release the lock before going to sleep.   Replacing the configuration data simply consists of preparing the new data, obtaining a write-lock on the semaphore, and replacing the old with the new before releasing the write-lock.

Of the two approaches, I prefer the latter one because it maintains only one copy of the data structure.   The incremental overhead of the locking semantics should be negligible.