User: Password:
|
|
Subscribe / Log in / New account

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.


(Log in to post comments)

Concurrent code and expensive instructions

Posted Jan 27, 2011 22:36 UTC (Thu) by PaulMcKenney (subscriber, #9624) [Link]

Sounds sort of like Haskell monads. ;-) I pointed one of the authors at your comment, perhaps it will be helpful to them.

Concurrent code and expensive instructions

Posted Jan 28, 2011 16:15 UTC (Fri) by nix (subscriber, #2304) [Link]

Sounds almost exactly like Haskell monads, if 'everything that could change' is set equal to 'the entire world'. (Of course monads were invented precisely to transform those annoying side-effects into nice clean function parameters, so this is not at all surprising.)


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds