DOS has no concept of multiple cores, much less threads. Multiprocessing in such an environment "works" mainly for the same reason why pthreads and friends "worked" in the decades before C++11 standardized a memory model for native code. The hardware and your code must conspire to work around the part that isn't thread-aware.

Nothing is really stopping you from using the underlying hardware for concurrent execution, but at the same time DOS (and possibly BIOS/UEFI???) will blow chunks if you don't carefully synchronize access to it. Cross-core communication works exactly the same as it does in kernel-mode systems programming; and you need to bring your own synchronization primitives on top of the ones x86 processors ship with. You're basically writing an OS kernel at that point; one that just so happens to support kexec-ing back into COMMAND.COM and using bits of it as a filesystem driver.