Would it be possible to abstract multi-threading ability for programs not originaly designed for such?

Question

Would it be feasible to provide (or further) multi-core threading ability for programs that weren't originally designed for such?

And doing so by creating a "virtual" CPU core (or for i7's with hyperthreading, virtual "virtual cores") which, to a program, the program sees it as a single core/thread, but on the other side of this virtual core is a program/tool/utility that splits the work across multiple cores/threads on its own? And for those programs already designed for multi-core support, the virtual core enabling an increase in the number of cores usable.

I feel this would be useful given the trend in recent years of increasing core counts vs. overall CPU speed increases in lieu of CPUs running up against Moore's Law "ceiling," and the seemingly slow or trailing push in software development to take advantage of these growing number of CPU cores.

I realize something like this probably wouldn't be simple or easy to accomplish, but I'm mostly wondering if it would be feasible to do.

Answer 1

For programs written in an imperative/procedural style, this is next to impossible because the separate threads may access shared data, and correct semantics for larger-grained parallelism can't be easily ensured.

Programs written in a functional style may be parallelized automatically since there's normally much less shared state, but it is still hard to automatically decide when the overhead of creating a new thread will pay off through improved overall execution time.

Answer 2

To a regular application program there are just threads. Whether the processor has multiple cores or uses an army of leprechaun to get things done is irrelevant. What matters is the tasks implemented by the application and whether these can be performed in parallel while maintaining the functionality or not.

Some applications can be reworked to benefit from threading, others can not. It all depends on the logic.

Answer 3

I think the closest you're going to get is something like OpenMP for C, C++, and FORTAN. This library allows you to parallelize some constructs like for loops simply by inserting a pragma or two before the code block:

void simple(int n, float *a, float *b)
{
    int i;
    // This assumes the blocks pointed to by a and b don't overlap
#pragma omp parallel for
    for (i = 1; i < n; i++) /* i is private by default */
        b[i] = (a[i] + a[i-1]) / 2.0;
}

It's not magic though. As the other answers have pointed out, the hard part of parallel processing is figuring out how to handle accessing shared data across threads of execution. A few problems don't need to share data across threads, and in that case OpenMP makes it trivial to parallelize existing code. In general though, you have to be able to recognize when data is being shared across threads, and choose the appropriate constructs to regulate access to that data. That can require some very hard and deep thinking, and may require a major refactoring of existing code.

Answer 4

This is the fundamental of all modern OS, the abstraction to virtualize the CPU is the Process and also the Lightweight Process, which is more commonly known as Threads and an even lighterweight version commonly known as Fiber/Green Threads.

Each program running inside a process (or a lightweight process, or green threads) is running inside a virtualized CPU core, as if it has sole control of that CPU. The process abstraction makes it so that the system can share a limited number of physical CPU cores with large number of Processes by preempting processes that aren't ready to run or have run out of its fair share of CPU time.