3 ms·
I guess we need to define more precisely what it means for a VM to "support concurrency". Based on your comment, I assume you mean that it's possible to write p
by blt 9y ago
I guess we need to define more precisely what it means for a VM to "support concurrency". Based on your comment, I assume you mean that it's possible to write programs for the VM that use something like the pthreads API. But you don't need multiple CPUs or special hardware to provide the pthreads API. The "concurrent threads, shared memory" model of execution is still meaningful on a single-cpu machine.
Given a single-CPU VM, you can write an assembly program that implements context switching and the thread control block data structure. Then you write a scheduler (OK, the VM needs a timer/interrupt to trigger the scheduler). thread.start(function) allocates some stack memory and a thread control block, which contains a pointer to `function` and to the stack memory you just allocated. Then `thread.start` inserts our TCB into the scheduler queue. All this stuff is implemented as software in the VM's machine language, it is not part of the VM itself. pthread_create and the Linux scheduler are not implemented in hardware either.
I guess if you want memory protection, you would need the VM to simulate a MMU.
On the other hand, if you actually want programs on the VM to be able to run on multiple CPUs of the host machine, then I agree you need some special support in the VM to do that.