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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4