jayshankar nair via Python-list <python-list@python.org> writes: > Is condition.acquire(threading.Condition()) similar to > lock.acquire(threading.Lock). Does both of get access to the lock. Can i use > condition.wait,notify with lock.acquire or i have to use condition.wait, > notify with condition.acquire. > cond.acquire() // can i replace with lock.acquire > > while count[ipID]> 1: > cond.wait() > if ipID == 0: > time.sleep(10) > > > count[ipID] = count[ipID] + 1 > > > cond.release() // can i replace with lock.release
The documentation tells you that a "condition" is always associated with a "lock". You can either pass in a "lock" object when you create a "condition" (in case, multiple "condition"s must share the same lock) or such an object is created automatically. The "condition"'s "acquire" and "release" methods call the respective methods of this lock. To determine whether you can call "lock.{acquire|release}" (instead of "condition.{acquire|release}") look at the implementation of the "condition" methods: if all they do is delegating to the "lock" methods, it is safe; otherwise, it is not safe. Anyway, you should use "condition.{acquire|release}" for clarity when working with "condition" (especially, calling its "wait", "notify*" operations) rather than use the "lock" methods *UNLESS* you have really good reasons to make use of the "condition -> lock" association. -- https://mail.python.org/mailman/listinfo/python-list