On Sat, 2008-03-01 at 15:46 +0100, Dirk Meyer wrote:
> > Ideally this code should allow foo() and bar() to execute in parallel,
> > but it doesn't. Sure you could create a separate mutex for foo() and
> > pass it to its synchronized() decorator, but that sucks.
>
> What do you suggest?
Don't do this:
def synchronized(lock=threading.Lock()):
This only ever allocates one lock, at import time. It does not create
new threading.Lock objects for each invocation of synchronized, as I
think you might be expecting based on this code. It's a common pitfall
in python.
Do this:
def synchronized(lock = None):
def decorator(f):
f.__kaa_synchronized_lock = lock or threading.RLock()
[...]
> @synchronized()
> def f1(self):
> critical
>
> def f2(self):
> uncritical
> with synchronized(self):
> critical
> uncritical
>
> That would be a hack to use the same function as decorator and inside
> a function, but it would be a very cool feature.
I'm not sure how this would work: would the critical section in f2() be
synchronized with f1()? In other words is this:
@synchronized()
def f1(self):
[...]
synonymous with this:
def f1(self):
with synchronized(self):
[...]
?
I guess this is ok, although obviously that's not what the code does
now. :) We'd need the same sort of
is-decorated-function-actually-a-method hack that's in timer.py.
This would be possible to implement (that is, synchronized can be either
a decorator or a context manager), I think.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Freevo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freevo-devel
