There are four completely separate cpu cores, not four program counters, four complete processors. naturally at some point the cores begin to share busses and eventually share with the gpu's busses to share peripherals and ram, etc.
start with bare metal on one processor core, the other three are sitting idle waiting/watching an address to jump to then they start executing that code, that is at least what someone figured out and I have successfully tried myself (there is a baremetal forum at the raspberry pi website).
once you go multi core you are basically writing programs for four computers that share resources, so you have to design it such that each talk to each other (shared memory, etc) or that some resources are completely owned by one core and the others code wont touch it. or one core owns a resource and the others ask that one core to do stuff for them. like four people in a car, ideally only one is driving, but maybe two can control the radio and thermostat, maybe everyone shares control over the dome light. If you dont etablish some rules then the radio is constantly changing volume and channel, the temp is going up and down, etc. in programming that simply means creating the rules and designing the software to those rules.
the arm docs spell it out. What is not spelled out is how you start up each of the cores as to some extent if not completely that is chip vendor specific and not an ARM thing. if you want to do baremetal programming reading chip vendor docs and schematics is a significant percentage of the job. For arm based products you need the correct arm docs for that core, and the chip vendors docs, unfortunately for the raspberry pi 2 they refused to (allocate resources to) make those docs (nor complete schematics) but we have learned how to spin up the other three cores (fairly trivial). if you are someone who is in the business of buying a significant number of those chips from broadcom for a product well that is another story, you sign the NDA and you get what you need, all the secrets.