Reinforcing what was just suggested (in code) ...

The main thread could be the one that gathers the work-requests, but it shouldn’t try to figure out which of the various child-threads might be the one that gets to do the next one.   (That is a race-condition, and unnecessary.)  

Simply place the new work-request onto a FIFO (first-in first-out) queue that n child processes are simultaneously listening on.   You know that one of them will get the message; you don’t know, and don’t care, which one.

The child threads really don’t care too much about the parent process, nor about their other siblings, nor about how many siblings there might be.   They simply:   wait for a request to arrive, carry it out, and send some kind of notification (through another queue...) that they have done so.   They do this until they are finally told (say, by another message...) to terminate.

In quite a few applications I have built and witnessed, the main thread basically has nothing to do, except maybe to keep the user entertained.   Everything is done by children:   one child accepts requests, n brothers and sisters do the work, and one child sends the responses back.   All the moving parts are stitched together using FIFO queues.