[Python-Dev] New PEP: 319

[Roman Suzi]

On Mon, 16 Jun 2003, Michel Pelletier wrote:

>> Obviously I could have done things differently.  I could have coalesced
>> all
>> the top 50 data into a single object and locked it or created a separate
>> lock for each item.
>
>    synchronize item:
>
>would create a (hidden) lock for each item for you.  Wouldn't this solve
>your problem of no two threads changing one item?  or do changes to any
>one top 50 item *require* locking all 50?  If they are independent that
>this is exactly the purpose PEP 319 serves.

Oh no... I have not thought about locking objects, but locking places of a
program from multiple entry. I do not think the whole business of locking
_objects_ is appropriate to do. And thus I think Michel should think about the
implementation of his locking infrastructure. Even in high-level terms
implementation seems fuzzy and prone to semantics misunderstandings.
And this became clear to me when all this discussion of top50 was
presented.

I think anonymous locking is bad idea. Locking based on syntactic
containment (?) is also problematic. The only obvious way is 
to have explicit lock.

Thus I understand that 

syncronize:
   lalala

means only that it could not be re-entered from other thread and
not that all objects encountered inside are "locked".

This makes

syncronize self.counter:
   self.counter += 1

looking silly.

And I must also say that examples from the PEP aren't convincing. All that
implicit locking on target objects is looking like magic. And as we know
explicit is better than implicit (*). This way I will never know why my
program consumed so much memory and it takes so long to make simple things:
and the answer is implicit locks lurking here and there, with every object.

(*sorry for being the first person to use the word implicit in the PEP
name ;-)

One more solution is to have same target-object blocks but with explicit
instantiation:

   def lalala(self, queue):
     syncronize AdHocLock(queue):
       do_something(queue)

The main idea here AdHocLock being a singleton which creates
a lock and shepherds a dict of locks, keys of which are for example
weak refs to objects.

So, making 

   def lalala(self, number):
     syncronize AdHocLock(number):
       do_something(number)

is no contradiction. We can as well have a constant:

   def lalala3(self):
     syncronize AdHocLock(3):
       do_something

This is not so good because it creates and maintains global structure (locks)
and thus two modules could have a conflict over same object id or number.

Much better solution, IMHO, is to use traditional explicit locks: no need for
new keywords, no need to worry that objects will have a shadow of accompanying
locks.

Sincerely yours, Roman Suzi
-- 
rnd@onego.ru =\= My AI powered by GNU/Linux RedHat 7.3