Be aware, threads do not run concurrently unless you have multiple cpus.

Even using a non-polling event (such as cond_broadcast), each of the threads will be started sequentially, but there is no guarentee of what order they will be started.

When each thread receives it's signal to start, it will the run for a complete timeslice (barring yields). The timeslice will vary from OS to OS, but typically might be somewhere between 3 and 20 milliseconds. With 10 threads, that means the last thread will have no chance of starting until at least .03 of a second after the first. Modern cpus can process a huge amount of data in this time. A crude test with a 2GHz cpu shows perl can iterate a loop incrementing a scalar 1_000_000 times or perform at least 500_000 exponentiations in this time.

Finally, there is no guarentee--in fact it is extremely unlikely--that your pool of threads will run on adjacent timeslices. Remember that the threads in your process are competing with every other thread in the system for timeslices, including all the high and real-time priority threads which will take presedence. In fact, it is almost impossible that your threads will get even numbers of timeslices. The usual pattern is that some threads will tend to dominate, and the other threads will be starved of CPU until one or more of the dominate threads terminates or goes into IO wait states.

The bottom line is that there is simply no way to synchronise threads. Indeed, any design that tried to synchronise threads is fundementally flawed.