[fpc-pascal] Re: GetAffinity\SetAffinity

Mark Morgan Lloyd markMLl.fpc-pascal at telemetry.co.uk
Fri Nov 22 20:28:13 CET 2013


Brian wrote:
> "... The critical sections you are using only protect each thread against
> itself, meaning they basically do nothing. Being inside a critical
> section is not a guarantee that you won't get preempted, but just that
> no other threads can enter the same section. ..."
> 
> The two threads do not share and variables and do not interact with one
> another. The question is ... as Mark has previously pointed out ... does
> Linux x86 allow setting hard affinity with threads where the program
> (process) runs on one CPU core and one or more threads run on another core? 

But they do share state in the context of the RTL :-/

I think what I'd try is skipping the RTL and going direct to a syscall 
for the output, since I think threading should be safe at that level. 
Possibly one of the compiler/RTL team would like to comment.

> It looks like all the threads must run on the same core as the block diagram
> at this link seems to imply.
> https://computing.llnl.gov/linux/slurm/mc_support.html
> 
> Mark : I found that sometimes coret_fail would run several times correctly ,
> and then when launched on launch N+1 would fail. It may just be luck of the
> draw that everything was running on one core when it ran correctly.

I'm afraid that I'm planning to spend the next few hours, and possibly 
days, catching up with some long-overdue SPARC and PPC testing- there's 
some fixed bugs on Mantis that I should have checked and my conscience 
is catching up with me.

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]



More information about the fpc-pascal mailing list