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.

  • Why the virtual cores? Pointless. You use the real cores. If there’s work that can be multithreaded that’s quite trivial to do with modern languages for a human developer, and close to impossible for some automated tool.
    – gnasher729
    Commented Jan 25, 2020 at 12:56
  • I'm not well versed on this, but if the program is designed in such a way to only utilize one or two cores, and the program itself can't or won't be changed by the developers, then a "workaround" being a third-party utility that creates the virtual cores the program expects and targets how it was designed to work with, but then on the back-end, a custom utility that then does the splitting of the virtual core's workload across multiple physical cores. Obviously the ideal would be for the programs themselves to do the splitting/utilizing. Commented Jan 25, 2020 at 13:05
  • 1
    @gnasher729: if it would be that trivial as you say, it could probably be automated. Don't confuse "it has become simpler with modern languages" with "it has become simple" - implementing concurrency correctly can be still extremely hard.
    – Doc Brown
    Commented Jan 25, 2020 at 13:14
  • 4
    All serious CPUs since the 90s already implement a kind of parallelization, called out of order execution: the CPU analyzes dependencies between machine code instructions and executes multiple tasks at the same time. For example, memory accesses are slow so the CPU can do useful work while accesses are pending. Some instructions are even executed speculatively when the inputs are not yet known, but the results need to be rolled back if the CPU guessed wrong. Hyperthreading is another technique to keep a waiting CPU busy. However, many real-world programs are IO-limited, not CPU-limited.
    – amon
    Commented Jan 25, 2020 at 13:32
  • 1
    @amon: even for those CPU-limited programs the kind of in-build parallelization you describe does not appear to be as effective (not even close!) as a programmer who reorganizes the algorithms on a larger scale, so they can utilize all the cores in a machine.
    – Doc Brown
    Commented Jan 25, 2020 at 15:56

4 Answers 4


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.

  • 1
    Yes, functional-style side-effect-free programs have the problem of being too parallelizable, which makes choosing what to keep together difficult. Commented Jan 25, 2020 at 14:53

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.

  • 2
    and even when parts of them can be reworked, Amdahl's law limits what good that does you. Commented Jan 25, 2020 at 13:53

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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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