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?

  • I'm sure I could word this a little better but I'm not quite sure how. I think the word guarantee could be thrown in there somewhere; let me know if this could be improved. – Qix Dec 1 '14 at 6:12
  • one of the things you can easily do on a multithreaded environment is a busy loop, doing that on a singlethreaded environment is program suicide (immediate deadlock) – ratchet freak Dec 1 '14 at 8:54
  • 4
    Given that many multi-threaded programs are executed on a single core of a CPU, there are no properties in a multi-threaded program that prevent execution on a single-threaded execution model. – Bart van Ingen Schenau Dec 1 '14 at 8:57
  • The networking question is trivial, because even a host that is not connected to any network can have the loopback interface (which can have multiple arbitrary ip addresses added to it, if necessary). Your perfect application can connect to other software (or other instances of itself) via that interface. If by "non networked" you mean that even the OS lacks any network capabilities, then distributed software would crash. – itsbruce Dec 1 '14 at 9:31

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.