On 28 Jun 2011, at 22:25, Hans-Peter Diettrich wrote:
Andrew Brunner schrieb:
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?
Not unless a speculative parallel execution environment is used
(either in software or hardware), but because of their speculative
nature those are by design transparent to the software (and afaik all
of them are still only in research stages).
If so, shouldn't there exist means (flags...) to tell the OS, that
FPC executables are not (yet) ready for such automatic parallelism?
Such flags don't exist because there is no need for them.
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?
Yes. That is the job of the operating system (which will do this by
inserting memory barriers, cache flushes etc).
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]
Indeed, it does not exist, unless there is a bug in the kernel of his
machine.
3) When above cache inconsistencies can occur, how can even a single-
threaded program work correctly?
Indeed.
Jonas
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
