[fpc-devel] C++ gets language-internal concurrency support

[Michael Schnell]

On 08/19/2011 02:15 PM, David W Noon wrote:
> Threads are not tied to processors.
I do know that in Linux the scheduler tries to keep a thread in a core 
if possible (even after re-scheduling the thread after preemption). This 
greatly increases cache performance.
> This is especially true in
> "managed" languages, where threads usually have process scope and
> consequently all run on the same CPU. [I.e. a thread with process scope
> cannot have CPU affinity distinct from that of the main thread in the
> process, whereas a thread with system scope can run wherever the
> operating system's CPU dispatcher sends it, possibly constrained by
> that thread's own CPU affinity mask.]
While I do understand what you mean, I never heard that defining CPU 
affinity in a way that a process only is allowed to use one core for all 
it's threads. If this is set, of course parallel tasks don't make any 
sense at all. I suppose that this can be set for special purposes, but I 
don't thinks that it's a standard setting (e.g. in Linux).

As a growing "class" of programs are defined to take advantage from a 
multi-core System - and I suppose most do this by distributing 
cycle-hungry tasks towards multiple threads - I understand that the 
normal way of the OS is to allow for multiple CPUs for a single 
application.

-Michael