Avoiding BlockedIndefinitelyOnSTM exceptions

[wren romano]

On Sun, Jul 20, 2014 at 5:22 PM, Gábor Lehel <glaebhoerl at gmail.com> wrote:
> On Sun, Jul 20, 2014 at 5:48 AM, wren romano <winterkoninkje at gmail.com>
> wrote:
>>
>> On Sat, Jul 19, 2014 at 11:24 PM, wren romano <winterkoninkje at gmail.com>
>> 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