The communication within the process i.e. threads do share the same address space. I never mentioned interprocess communication - however, again can be implemented w/o the OS (!!) through shared memory, once the memory is allocated/shared the OS doesn't kick in. The approach again is used to low latency process communication, it requires polling and one core per process polling but it's a lot faster than socket on 127.0.0.1 (also a lot more cumbersome to use)
Mutex/Lock is trivial to be implemented w/o any races given CAS alike (which is a CPU instruction[s] and doesn't have anything to do w/ the underlying OS). You do not need any round robin, just queues with waiters and the mentioned park/upark. "Craig, Landin, Hagersten or CLH lock queue" if you need more info, the queue is not required to be use with spin-locks, either. No kernel privileged CPU (or memory) instructions are necessary.
The Java VM does it internally because it rolls its own "threads" and as I said in an original post , its simulates a mini VM.
Baring green threads for solaris 13 years ago, java has always been using native threads. I mean always. Saying otherwise is pure ignorance. Contrarily on popular belief Java VM is not any mini-VM that emulates OS, it maps most of its needed native functionality straight to OS. I can say I know hotspot java source/impl. well.
Btw, you do apparently love buzzwords but you might try aquiring some knowledge first. It tends to help in these sorts of arguments.
This is definitely the most inaccurate description of me ever. I am exactly the opposite of buzz whoring. Just to help you out I'd say I do concurrent code for living.
My last post here - answering baseless flame ain't fun especially when the flames contain misinformation and lack of basic understandings.