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. -- http://mail.python.org/mailman/listinfo/python-list