I'm not sure it needs a special name. It's the default model that almost everyone learns first, shared-memory parallelism/concurrency. It's the whole reason that semaphores and mutexes were developed (to avoid contention for the same resource or resource set from multiple threads of execution).

Yes, but I also mean that parallelism to be atomic/non-locking. afaik only Java/C# can do this on a high-level (without going back to atomic arrays in C) but I still can't explain why, the best I found so far is:

"Many lock-free structures offer atomic-free read paths, notably concurrent containers in garbage collected languages, such as ConcurrentHashMap in Java. Languages without garbage collection have fewer straightforward options, mostly because safe memory reclamation is a hard problem..." - Travis Downs https://travisdowns.github.io/blog/2020/07/06/concurrency-co...

But it seems there is also some benefit to have a VM in addition to a GC for this joint/atomic parallelism.

I wrote that. The problem I was getting at is that it's fairly easy to write various types of lock-free structures in native langues, but you almost always run into the "memory reclamation" problem.

E.g., you can look up something like a lock-free linked lists, the first of which were described decades ago. They have an algorithm to delete a node from the list, but what often isn't emphasized is that you can't just free that note by calling `free()` on it, because you don't know if any other readers might happen to have a reference to that node, and thus may access the underlying memory. If you free it, they might access freed memory.

In general, this is a hard problem to solve. You can wait, but how long is long enough?

Garbage collected languages solve this more or less automatically: there is no explicit free() but instead the GC determines when there are no more live objects and frees it for you.

This isn't unsolvable in native languages, but none of the solutions are as clean and tradeoff-free as you'd find in a GC'd language.

Look up MISD. I think that’s the idea you’re getting at, there really isn’t a lot of hardware support for it which is why for more complicated structures you’re pushed towards higher level languages.

Historically, this is known as "multiprogramming". Multiple programs making forward progress inside the same computer, via interleaved or concurrent execution, the latter being called "multiprocessing".