On 18/09/2011 00:26, Dennis Lee Bieber wrote:
On Sun, 18 Sep 2011 07:35:01 +1000, Chris Angelico<ros...@gmail.com>
declaimed the following in gmane.comp.python.general:
Is it just that nobody's implemented it, or is there a good reason for
avoiding offering this sort of thing?
Any asynchronous "kill" runs the risk of leaving shared data
structures in a corrupt state. {Stupid example, but, in pseudo-Python:
import time
class Account(object):
def __init__(self, initial=0.0)
self.balance = initial
myAccount = Account(100.0)
yourAccount = Account(100.0)
accountLock = threading.Lock()
def threadWork(lock, a1, a2, rate):
while True:
time.sleep(rate)
lock.lock()
t = a2.balance / 2
a1.balance += t
#say a thread.kill kills at this point
a2.balance -= t
lock.release()
# create/start thread1 passing (accountLock, myAccount, yourAccount, 60)
# create/start thread2 passing (accountLock, yourAccount, myAccount,
120)
time.sleep(300)
thread1.kill()
So... Thread1 may be killed after one account gets incremented but
before the other is decremented... And what happens to the lock? If it
doesn't get released as part of the .kill() processing, they program is
dead-locked (and the magically appearing money will never be seen). If
it does get released, then the sum total of "money" in the system will
have increased.
[snip]
The lock won't be released if an exception is raised, for example, if
'a1' isn't an Account instance and has no 'balance' attribute. Using a
context manager would help in that case.
--
http://mail.python.org/mailman/listinfo/python-list
