On Jan 12, 1:37 am, [EMAIL PROTECTED] wrote: > On Jan 11, 8:04 pm, Paul Rubin <http://[EMAIL PROTECTED]> wrote: > > > > > [EMAIL PROTECTED] writes: > > > Could you: > > > > lockerA= Locker( listA, listB ) > > > lockerA.op( listB.reverse ) > > > lockerA.op( listA.pop ) > > > > Where lockerA ops acquire the locks on all its threads? > > > I don't understand that question. The main thing to understand is > > that multi-threaded programming is complicated (especially if you're > > after high performance), and very difficult to get right without > > knowing exactly what you're doing. The generally preferred approach > > in Python is to keep things simple at some performance cost. > > > Your Locker approach above looks sort of reasonable if you can be > > absolutely sure that nothing else can mess with listA or listB > > concurrently with those locker operations. Normally you would put > > listA and listB into a single object along with a lock, then do > > operations on that object. > > > You might check the Python Cookbook for some specific recipes and > > sample code for this stuff. If you've used Java, Python's general > > threading mechanisms are similar, but they are in the library rather > > than built into the language (i.e. there is no "synchronized" > > keyword, you have to do that locking explicitly). > > > What is the actual application, if you don't mind saying? Are you > > sure that you really need concurrency? > > I'm writing an NxN observer pattern, mostly for my own personal > exploration. Two threads -might- be calling 'Disconnect' at the same > time, and I can't even guarantee that the function runs properly. > > for emelem in [ e for e in emlist if e.func is func ]: > try: > emlist.remove( emelem ) > except ValueError: > pass
Is there a reason you're using a list, rather than a dict? Note that each call to list.remove() is O(n), whereas deleting a key from a dict is O(1). -- http://mail.python.org/mailman/listinfo/python-list
