Minimalistic Software Transactional Memory

[Michael Sparks]

Fuzzyman wrote:

>> STM seems more in
>> keeping with Kamaelia being generally lock-free.
> 
> STM isn't lock free - it just abstracts the locks away from the
> 'user'. You still need to lock around committing the transaction.
> 

I perhaps phrased what I meant too tersely.

Kamaelia isn't lock free either. It's generally lock free. User code
however, doesn't ever see locks... (Though threaded components do
communicate over thread safe Queues which contain locks internally.
Generator components don't use locking)

I suppose the reason why I like STM (conceptually) is because it appears to
follow the same sort of idea - the user of the code doesn't have to worry
about locks - the just have to worry about whether they're using the system
correctly or not. :-)

Based on this, I think I'm right in thinking then that given the code I
posted, that at minimum I need locking here, since it is the critical
section.

    def set(self, key, value):
        # Attempt to acquire lock
        if not (self.store[key].version > value.version):
            # Also assuming we have lock
            self.store[key] = Value(value.version+1,
                                    copy.deepcopy(value.value), self, key)
            value.version= value.version+1
            # Release lock
        else:
            # Also do this if we can't get access to the lock
            raise ConcurrentUpdate

I know I then have a choice of locking the value (ie a lock specific to
self.store[key]) or the self.store as a whole. Depends on how antisocial
you want the locking to be I suppose :-)

> Other threads accessing the data during the transaction should see the
> old values until the commit is successful.

The implementation I'm suggesting means that other threads would see the
old values until the try to commit their changes. (I'm after something
simple since I'm expecting to deal with simple cases)

Many thanks :)


Michael.