Take an arbitrary "perfect" multi-threaded program, on an arbitrary multi-threaded platform, using an arbitrary programming language.
Assuming that this "perfect" multi-threaded program:
- is flawless in terms of race conditions
- handles shared memory perfectly
- may/may not use a locking mechanism (thread suspension or mutexes fall into this category)
- has no unforeseen bugs (100% bug free)
- uses no complicated language/system specific constructs that cannot be translated to another system under any circumstance
and assuming that this arbitrary platform
- is/isn't POSIX compliant (doesn't matter)
- uses a familiar threading model
- doesn't turn the locking mechanism into a whirlwind of voodoo spaghetti code (arguably)
and assuming this arbitrary language
- doesn't use any domain-specific threading constructs (such as Java's
- is platform agnostic at the very core (such as C and variants)
- can be cross-compiled to many different architectures/platforms (isn't limited to the platform its on)
can the code inherently be implemented in such a way that it runs as expected on a single-threaded platform?
For instance, in lieu of threads the single-threaded platform uses a co-routine-like model to simulate threads. Is there a fundamental design flaw with such concepts that would inhibit the ability to run the program in this thread-absent/thread-emulated environment?
The answer to this broad question is very platform-specific, but as I alluded to earlier I'm interested in whether or not there is an inherent proprietariness with multi-threading that makes them impossible to port to non-threaded environments.
Additionally (and more concretely), are there any specific, mainstream platforms/architectures that wouldn't allow such a scenario to occur?