[Python-ideas] Optimistic Concurrency

[Terry Reedy]

Leif Walsh wrote:
> On Tue, Oct 14, 2008 at 1:38 PM, Terry Reedy <tjreedy at udel.edu> wrote:
>> It does not strike me as practical for Python.
> 
> Probably true, but let's see....

You persuaded me to rethink this...

>> 1. It starts with copying data.  Clients accessing a database server already
>> do this.  Threads accessing *shared* data normally do not.
> 
> Agreed, but if I want them to, they should (and I should be able to
> tell that to python concisely, and have python understand what that
> means for concurrency).

Suppose shared data consists of mutable collections.
Let the program units that share the date follow this protocol 
(discipline) for editing members of a collection.

old_id = id(member)
edit_copy = collection.member # or collection[index/key] or whatever
edit edit_copy
done = False
while not done:
   atomically:
     if id(edit_copy) == old_id:
       collection.member = copy # by reference copy, not data copy
       done = True
   if done: break
   recover(edit_copy)

'Atomically' could be by a very short term lock or perhaps a builtin C 
API function if such can run 'atomically' (I just don't know).

I believe this will work if all editors edit at the same level of 
granularity.  Certainly, mixing levels can easily lead to data loss.

>> 2. Any edit (change) may be discarded in part or in whole.  Human operators,
>> informed of the rejection, must (and 'somehow' do) decide what to do.
>>  Wrapping every assignment to shared data with a pre-programmed
>> RejectionException handler would usually be a huge burden on the programmer.
> 
> It would be a huge burden, but perhaps it could be an option for the
> especially ambitious programmer.

Or the program might ask a human user, which was the use-case for this idea.