Re: Avoiding BlockedIndefinitelyOnSTM exceptions

On Sun, Jul 20, 2014 at 5:22 PM, Gábor Lehel wrote:

On Sun, Jul 20, 2014 at 5:48 AM, wren romano wrote:

...

On Sat, Jul 19, 2014 at 11:24 PM, wren romano wrote:

...

-- | The second argument allows handling 'BlockedIndefinitelyOnSTM' etc. runSTSTM :: (forall s. STSTM s a) -> (STMError -> b) -> b

That should've been something more sensible, like:

atomicallySTSTM :: (forall s. STSTM s a) -> (STMError -> b) -> IO (Either a b)

Yeah, that's not quite what I meant either. Will have to think about it more.

Wouldn't combining it wih ST defeat the purpose of STM? The purpose of STM being to synchronize access to shared variables using atomic transactions. If all the variables in your atomic transaction are guaranteed to be local and not touched by any other transaction, which I believe the above type says, then you don't need a transaction at all.

Or was the idea to create some kind of outer scope within which individual atomic (sub)transactions may share access to variables, but not without?

Yeah, the idea is to create smaller scopes to collect all the related references into a single heap/region, isolating them from other heaps, allowing the heap to be gc'ed in one go, etc. Arranging local scopes is generally a good idea since global scope is non-compositional. STM just says that heap interactions are transactional, it doesn't say there can be only one heap/region. Indeed, there can be performance benefits for adding regions to thread-based parallelism like STM. Since threads accessing disjoint regions cannot interfere with one another we have very strong guarantees about their data-flow and synchronization properties. This, in turn, can be used by the runtime to reduce memory traffic: associate each heap with a core, distributed as evenly as possible over the cores, and schedule all the threads over a given heap to be run on the core for that heap (or on "nearby" cores). Similarly there can be runtime performance benefits since we can use tricks like card marking to quickly check whether any other thread has modified our region; if not, then commit immediately; if so, then do the expensive check of running through the STM log to see if there's really a conflict. -- Live well, ~wren