I think it will be useful to have a decorator like this one on the threading module:

def synchronized(func):
    """A decorator to make a function execution synchronized.

    Examples:

    @synchronized
    def foo():
        pass

    class Foo:
        def __init__(self):
            self.__syncdata = None

        @property
        def syncdata(self):
            return self.__syncdata

        @syncdata.setter
        @synchronized
        def syncdata(self, value):
            self.__syncdata = value
    """
    if not hasattr(func, "__lock"):
        func.__lock = threading.Lock()
    def _synchronized(*args, **kwds):
        with func.__lock:
            func(*args, **kwds)
    _synchronized.__doc__ = func.__doc__
    return _synchronized

What do you think?

Writing such a decorator is pretty trivial to do.  On the other hand, I've done it often enough that I could be convinced it is useful to add.

I think it would be better to have a decorator generator that takes a lock as its argument, however, since an application might well want to use the same lock for sections that it doesn't make sense to decorate, or use an RLock instead of a lock.  If no lock is passed, a default Lock could be created.

Oh, I misread your code.

The code I'm working on uses the lock to serialize several different functions, and your decorator wouldn't work for that.

I'm not sure how useful that is in practice. Often you want to use the same lock accross several functions or methods.
Also, I think it would be more accurate to call this "serialized" than "synchronized".

Ok, you are right, serialized is the right name. Also, passing the lock to the decorator will the correct option.

What about this?

def serialized(lock):
    def _serialized(func):
        def __serialized(*args, **kwds):
            with lock:
                return func(*args, **kwds)
        __serialized.__doc__ = func.__doc__
        return __serialized
    return _serialized

"synchronized" has the merit of reusing Java's denomination, which this decorator intends to mimic, see http://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html

Basically, synchronize works with the object/class (implicit) reentrant lock.

It looks like this is not very interesting after all.

Are you saying that because you've lost interest, or because you think we have?  Sometimes things get lost here for a while, but picked up again later...

David, I think this doesn't deserve to be part of the library since it is trivial to write and it is just a particular use case.

Adding it as an example in the threading module's documentation might be a good idea, what do you think?

I have never done any Java, but @serialized doesn't look like an useful idiom to me, so I don't think it would be worth giving as an example in the docs.