"Allocation of workers are assigned by the compiler at the begining of the parfor cycles? "
2/3 of the iterations are pre-determined. The other 1/3 of the iterations are held in reserve and are given in smaller chunks as workers finish their tasks.
"So is it possible that one worker do nothing ineffectively, because always getting 'countinue' and finish the job much earlier than the others?"
Yes, it is possible. Once a worker has been given a chunk of iterations, it is responsible for finishing all of the chunk. If one of the iterations is taking a long time and other workers have nothing to do but there are remaining iterations, then those iterations are not handed over to the other workers.
parfor assumes that each chunk of iterations will take more or less the same time, on average -- that even if one particular iteration takes longer, that "probably" the chunk also got some shorter iterations. If it is possible in your situation that there is a "run" of longer iterations that might happen to all get allocated to the same worker with the other workers mostly getting much shorter tasks, then instead of using parfor(), you should use batch() or parfeval() for the iterations.
