If I understand what you're asking, it's possible, but it's a very, very bad thing.
The canonical example of what you're describing would be maintaining a counter which is incremented by multiple threads. This requires almost nothing in therms of computing power but requires careful coordination among the threads. As long as only one thread at a time does an increment (which is actually a read followed by an addition followed by a write), its value will always be correct. This is because one thread will always read the correct "previous" value, add one and write the correct "next" value. Get two threads into the action at the same time and both will read the same "previous" value, get the same result from the increment and write the same "next" value. The counter will effectively have been incremented only once even though two threads think they each did it.
This dependency between timing and correctness is what computer science calls a race condition.
Race conditions are often avoided by using synchronization mechanisms to make sure threads wanting to operate on a piece of shared data have to get in line for access. The counter described above might use a read-write lock for this.
Without access to the internal design of Dragon Age: Inquisition, all anyone can do is speculate about why it behaves the way it does. But I'll have a go based on some things I've seen done in my own experience:
It might be that the program is based around four threads that have been tuned so everything works when the threads run mostly-uninterrupted on their own physical cores. The "tuning" could come in the form of rearranging code or inserting sleeps in strategic places to mitigate race-condition-induced bugs that cropped up during development. Again, this is all conjecture, but I've seen race conditions "resolved" that way more times than I care to count.
Running a program like that way on anything less capable than the environment for which it was tuned introduces timing changes that are a result of the code not running as quickly or, more likely, context switches. Context switches happen in physical (i.e., the CPU's physical cores are switching between the work its logical cores are holding) and logical (i.e., the OS on the CPU is assigning work to the cores) ways, but either is a significant divergence from what would be the "expected" execution timing. That can bring out bad behavior.
If Dragon Age: Inquisition doesn't take the simple step of making sure there are enough physical cores available before proceeding, that's EA's fault. They're probably spending a small fortune fielding support calls and emails from people who tried to run the game on too little hardware.