[fpc-pascal] CPU affinity of TThread descendants

[Marco van de Voort]

In our previous episode, "Vinzent Höfler" said:
> > > [I.e., I want all my threads to be runnable by any CPU inside the box.]
> > 
> > No CPU affinity is imposed as far as I know; 
> > Under Linux, this is not possible, at least I've never heard of such a
> > call.
> 
> sched_set_affinity()
> sched_get_affinity()
> 
> (Now you've heard. ;)
> 
> The default for the CPU masks should be all 1s though, so the scheduler
> should distribute the threads evenly to all available CPUs. But... AFAIR
> the affinity mask is inherited by child processes, so maybe the main
> thread already has some affinity mask set (well, I don't see no reason why
> it should, but you never know).
 
> So for the original poster I'd suggest inserting a sched_get_affinity()
> call and check the resulting bit mask. If that's not all 1s, one should
> investigate the reason... if it is, then maybe the scheduler detects too
> many dependencies between the threads, so it doesn't distribute the thread
> on both CPUs, or maybe there's one totally different reason for the
> behaviour...

Maybe the dynloader tries to detect somehow if the binary is modern, by
searching for some gcc generated symbol that is not there in the FPC bins,
and reverts to something old. (e.g. to keep older threading code running).

Note that there is also a trend towards more asymetric multiprocessing, as
already a dual cpu system of multicore processors is not symmetric anymore
(moving threads between CPUs too often decreases cache utilization). 
It might be a byproduct/bug of such modifications in that particular kernel,
specially if he is on a distro that likes to add own patches to kernels.
(since it seems the OP is using a dual singlecore cpu system)