Andrew Brunner schrieb:
On Tue, Jun 28, 2011 at 9:43 AM, Michael Schnell <mschn...@lumino.de> wrote:
On 06/28/2011 04:31 PM, Andrew Brunner wrote:
how developers
can force code execution in order w/o using a third party library?
Execution in order only makes sense when there is another thread that relies
on this order.
Wrong. Sigh... Order of execution is paramount just about everywhere.
It can be disastrous if not understood.
Remember ***cores!=threads*** people.
If your experience is really that chaotic, I think it's worth some
deeper investigation.
1) Can one thread be executed on multiple cores, at the same time?
If so, shouldn't there exist means (flags...) to tell the OS, that FPC
executables are not (yet) ready for such automatic parallelism?
2) When a thread wanders around, from one core to another one, shouldn't
be the starting conditions (CPU state, caches) exactly in the state when
the thread was stopped on the previous core?
Isn't that effect caused by your monitor, that forces the thread into
suspended state frequently?
You seem to assume that the cache of the previous core may contain some
updated data, that was not yet written back into RAM when the thread is
resumed on a different core, whose cache happens to contain other
values? This really would be a very big problem :-(
[So big that I cannot believe that it really exists]
3) When above cache inconsistencies can occur, how can even a
single-threaded program work correctly?
A little chance exists, that an thread moves so often between two cores,
that both caches contain copies of the process-local data. But this
never should cause trouble, because single-threaded code was never
required to use Interlocked access to its private data.
3.1) Chances are higher for a multi-threaded application, where the
caches can contain any number of copies of shared (main thread) memory
areas.
But what would this mean to threaded code in general? I cannot believe
that thread-aware code must use Interlocked access to *all* variables,
even in the main thread, because no procedure can know from which thread
it is actually called, in which core.
That said I have some doubts, regarding your conclusions. Can you run
your test again, assuring that only one thread can access the list at
the same time, but *without* the Interlocked updates?
DoDi
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
