Concurrent code and expensive instructions
Concurrent code and expensive instructions
Posted Jan 27, 2011 18:32 UTC (Thu) by iabervon (subscriber, #722)Parent article: Concurrent code and expensive instructions
The usual way for theory to take into account side effects is to have the function accept and return a big structure that has everything that could change in it. That is "lock()" implicitly takes the memory that its argument is a pointer to, and implicitly returns it with a new value. Of course, the architecture's calling conventions don't have to arrange for these exchanges because the universe takes care of it (that is, when a function returns, it doesn't have to report its changes to its caller in order for the RAM to give the updated values); on the other hand, this is why values read from memory and stored in callee-saved registers have to be reloaded after function calls.
