Uses of barriers for one main thread controlling n threads
The threading mechanics mostly look correct.  Your main thread and your subthreads only share the mCommandToExecute and commands variables.  The subthreads only read them between mWaitForCommand and mWaitForAllDone, and the main thread reads and writes the mCommandToExecute between mWaitForAllDone and waitForCommand.  So no one is writing to this data while anyone else is reading it, and your data is thread-safe.

However your subthreads do not have any exit condition, so I expect the pthread_join will hang on the first one.  When you reach that point, all your subthreads will be waiting for the next command.  Joining the thread does not terminate it.  It simply allows you to synchronize their termination. You need to add some signal for the subthreads to terminate, and then you need to invoke that signal and then pthread_barrier_wait(mWaitForCommand) to allow each subthread to proceed to check the termination signal.

One simple way to do this, if it's practical, would be to make the termination step the final "command".  Rather than sending the termination command, the subthreads could recognize it and just return immediately.  Your main thread would need to avoid waiting on mWaitForAllDone for that last command, though.

I assume you will have some other code which handles lost connections, closing the accepted connections after the threads terminate, etc.  You do not seem to allow for stalled threads such as might occur in many network situations. If a client does stall, it will stall your entire system of threads.  I assume this is intentional or else you have timeouts and handlers for such occurrences in your real code.