What you're referring to is called thread sychronization (sometimes, or thread locking, among other things) and locks for variables, atomic writes etc. . If your program is multithreaded then it is basically built to run on a multicore already as the threads running on one processor can still get out of sync quite easily. Threads getting out of sync isn't a really bad problem unless they have to talk to each other a lot, whether directly or through memory, in which case the slowest thread ruins the day,
Threads can run happily out of sync, and can even communicate out of sync, but you get data concurrency problems between processor caches, meaning, say, the game engine locks the positions of all ships and writes new positions based on physics calculations, but if something else has even one locked, unless this is expected and dealt with in the code, the engine will have to wait for the other thing to release the lock. Where this gets game-droppingly bad is when two things are waiting for each other to release locks, forever, and thus the lock hang is born.
It still requires a lot of code modification, but the principles used to build a multithread engine can be ported over to multicore. Unless sins isnt really multithread (aka one "main" thread with several smaller threads). If this is the case then the game is essentially running like a script and more cores won't do anything.
Anyway, the biggest issue with the sins code, as far as i can tell, isn't cpu utilisation, its texture memory. It seems that some sort of high priority cache holds all of the textures at once (1.3 GB on my machine, plus the video mem, 512 mb worth of it 
), so that the video card doesn't have to load them to memory all the time, allowing for smooth transitions from no-tex(zoomed out with icons) to all-tex (zoomed in to a fleet battle). Other than texture compression, the likes of which i've never heard of, nothing can really fix this issue. Unless you do what the l4d people did, which is to minimize the base textures and use masks to achieve the desired results. I think you can get a root(x) reduction in consumed memory that way, not sure though...
