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
synchronized
keyword) - 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?
4
There are two main types of multitasking:
- Cooperative – where code explicitly calls a function to say “do something else now”
- Pre-emptive – where the threading system automatically stops one thread to allow another to run
These days, most multitasking code is pre-emptive, although event driven code (e.g. Twisted) is cooperative. I do remember using Visual Basic in the 90s and within long running jobs, having to put in calls to DoEvents. That was cooperative multitasking.
The distinction matters, because if your app is coded for pre-emptive multitasking, you can’t switch it to cooperative, unless you make substantial modifications. In that sense, the answer to your question is no – you can’t take a pre-emptive threaded program and make it run cooperatively using coroutines.
However, if your operating system provides a fine-grained alarm function, it is usually possible to write your own pre-emptive threading library. Roughly speaking, you have an alarm every 50ms or so, and switch to the next waiting thread. So in this sense, the answer is yes – you start by writing a pre-emptive threading library for the single-threaded platform, then you port your application quite easily.