jaoo - software transactional memory
Now back in London after the JAOO conference, the next session I attended was 'Back to the Future: Functions + Transactions' presented by Satnam Singh. The key concept he presented was Software Transactional Memory which uses concepts we are familiar with from database transactions. Effectually concurrent access to the same memory is allowed but we check for consistent state before we write back any results, if the underlying memory has changed (someone got there before us) then we abort the transaction.
It's a nice idea as among other things it avoids a lot of the locking issues around normal shared memory models. The code showed was a functional language with monads used as the implementation of STM, this took me way back: my final year project an uni was about adding monadic input/output in gofer. Of course, as with the previous talk, it's not clear when or how these ideas will come across to mainstream languages. Satnam went on to show us how these idea's could be used for composing more complex interactions.
Some concerns I came away with was the retry model, so if the memory has changed and we abort the transaction when do we retry? Can we get into a situation where we retry forever? I'm sure they've got these things covered, and I just need to read up on the subject more.
On a final note there was a question about how we think about parallelism. So one school of thought holds that we find concurrency hard to deal with because we have been trained (via school and then uni) to think in a sequential way. Satnam seems to be in the other camp, that we instinctively think in a sequential way and hence we struggle with parallelism. I'm not so sure, but if I look at the abstractions we have for dealing with parallelism in mainstream languages I can easily understand why people find it difficult.
It's a nice idea as among other things it avoids a lot of the locking issues around normal shared memory models. The code showed was a functional language with monads used as the implementation of STM, this took me way back: my final year project an uni was about adding monadic input/output in gofer. Of course, as with the previous talk, it's not clear when or how these ideas will come across to mainstream languages. Satnam went on to show us how these idea's could be used for composing more complex interactions.
Some concerns I came away with was the retry model, so if the memory has changed and we abort the transaction when do we retry? Can we get into a situation where we retry forever? I'm sure they've got these things covered, and I just need to read up on the subject more.
On a final note there was a question about how we think about parallelism. So one school of thought holds that we find concurrency hard to deal with because we have been trained (via school and then uni) to think in a sequential way. Satnam seems to be in the other camp, that we instinctively think in a sequential way and hence we struggle with parallelism. I'm not so sure, but if I look at the abstractions we have for dealing with parallelism in mainstream languages I can easily understand why people find it difficult.
0 Comments:
Post a Comment
<< Home