[fpc-other] Re: SMP > 2 core Cache issue with Posix threads

[Jonas Maebe]

On 01 Jul 2011, at 19:59, Andrew Brunner wrote:

> IMO, this statement is pretty bold/broad.  Meaning interlocked
> assignments as defined will ensure cache coherence as apposed to
> CrticialSections which are meant to minimally block *write* access if
> not read/write access.

CriticalSections as defined by both Posix and Win32 API do ensure cache coherence where it's needed (on entry/exit), because they include memory barriers (at the very least read barriers on entry and write barriers on exit; the reason is that if you don't have that, then the critical section simply does not protect/block anything at all due to instruction reordering by the hardware). There is no need whatsoever to constantly synchronise the caches between cores for memory accessed inside a critical section, because the whole point of having a critical section is to make sure that the data used inside it is only used by one core at a time.

The problem you have with a thread migrating from one core to another causing data corruption simply means that your code has a bug (as you mention yourself, it's quite complex, so that is not unreasonable). Using atomic accesses inside critical sections may hide that bug, but that probably makes your code slower than in case the bug would be fixed properly (and these atomic accesses may not even hide the bug on all current or future processors, even if you limit yourself to x86 and x86-64, since even their implementations keep moving further and further towards a "total store ordering"-style memory model).

And the discussion is now again at exactly the same point as the previous thread that I stopped (about low-level multithreading programming concepts). Unless someone can post code that demonstrates an actual problem with the compiler or RTL, there is no use to keep posting speculation about how a potential bug in the compiler or RTL could cause this kind of behaviour (you could start such a discussion about any bug in any person's program, claiming that it might be caused by the compiler/RTL and then endlessly continue discussing related topics without ever getting a step closer to actually discussing the compiler/RTL itself). Hence it's off topic for the fpc-devel list.

So this new topic is now also placed under moderation on fpc-devel.

Please do not start a third topic about it on fpc-devel.


Jonas
FPC mailing lists admin