[issue18078] threading.Condition to allow notify on a specific waiter

Raymond Hettinger added the comment: Marking this as closed/rejected for the reasons listed above. Thank you all for the thoughtful and intelligent discussion. -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracke

[issue18078] threading.Condition to allow notify on a specific waiter

Richard Whitehead added the comment: Thanks João. We are working on a medical prototype, and I wouldn't want to rely on our own version of something so fundamental without having a thorough test harness for it, which would obviously be quite time-consuming, and something of a dead-end. I've

[issue18078] threading.Condition to allow notify on a specific waiter

João Bernardo added the comment: Don't keep your hopes up. People here don't like implementing features they don't understand about even if they could verify elsewhere it works well. My solution at the time was to create a decent "Condition" class based on the original one (subclassing this o

[issue18078] threading.Condition to allow notify on a specific waiter

Richard Whitehead added the comment: Condition.wait_for_any is still a desirable feature, e.g. to wait on multiple command queues, or a work queue and a command queue. Is there any chance of pulling this into the latest version? -- nosy: +richardnwhitehead ___

[issue18078] threading.Condition to allow notify on a specific waiter

Changes by Raymond Hettinger : -- assignee: -> rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http

[issue18078] threading.Condition to allow notify on a specific waiter

João Bernardo added the comment: Seems like "just because I never used I don't support". Boost C++ libraries has a wait_for_any functionality to synchronize futures. C# has a WaitAny in the WaitHandle class (like our Condition). Another problem is: the Condition class cannot be easily subclass

[issue18078] threading.Condition to allow notify on a specific waiter

Charles-François Natali added the comment: > FWIW, I don't support adding this functionality. I don't see precedents for > Condition Variables behaving this way in other languages. Also, I don't > think it is worth the added complexity, learning curve, and maintenance > burden. Condition varia

[issue18078] threading.Condition to allow notify on a specific waiter

Raymond Hettinger added the comment: FWIW, I don't support adding this functionality. I don't see precedents for Condition Variables behaving this way in other languages. Also, I don't think it is worth the added complexity, learning curve, and maintenance burden. Condition variables are us

[issue18078] threading.Condition to allow notify on a specific waiter

João Bernardo added the comment: I've been thinking about returning a list on "wait_for_any", but that way you will not be able to implement "wait_for" using it! "wait_for" will return False on timeouts while "wait_for_any" will return a list with some conditions(evaluates to True). Also, "wa

[issue18078] threading.Condition to allow notify on a specific waiter

João Bernardo added the comment: > 1) It should check all predicates. OK. Maybe later there could be an option for customization? > 2) It should return a list of ready conditions. OK. > 3) It should *not* accept a list of conditions. The list option would be to simplify the "wait" method... Avo

[issue18078] threading.Condition to allow notify on a specific waiter

Richard Oudkerk added the comment: IMHO 1) It should check all predicates. 2) It should return a list of ready conditions. 3) It should *not* accept a list of conditions. 4) from_condition() should be removed. Also notify() should try again if releasing a waiter raises RuntimeError because it

[issue18078] threading.Condition to allow notify on a specific waiter

João Bernardo added the comment: > Charles-François's point about the algorithmic complexity is > legitimate, so I think he was actually waiting for you to amend > your patch ;) This doesn't seems to be the actual issue as it would require a big change for something that wasn't proven importan

[issue18078] threading.Condition to allow notify on a specific waiter

Antoine Pitrou added the comment: Charles-François's point about the algorithmic complexity is legitimate, so I think he was actually waiting for you to amend your patch ;) -- ___ Python tracker __

[issue18078] threading.Condition to allow notify on a specific waiter

João Bernardo added the comment: ping. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.or

[issue18078] threading.Condition to allow notify on a specific waiter

João Bernardo added the comment: (ping) It would be nice to have the feature on 3.4. What changes should I do to the patch? Is anyone else working on that? -- ___ Python tracker

[issue18078] threading.Condition to allow notify on a specific waiter

João Bernardo added the comment: > Here, removing a thread > from a wait queue other than the one from which it was signalled is > O(waiting threads). To be fair, You will probably never have more than a few hundred/thousand threads on a process. Usually you'll work under a few dozen threads.

[issue18078] threading.Condition to allow notify on a specific waiter

Charles-François Natali added the comment: > Which just means that waiting on C conditions is C times more expensive than > waiting on 1 currently is. That seems reasonable enough to me, and anyway, > I would expect C to be fairly small. Waking up a single thread (through notify()) is currently

[issue18078] threading.Condition to allow notify on a specific waiter

João Bernardo added the comment: > BTW, I think it would be better to have wait_for_any() > return a list of ready conditions rather than a boolean. That was the original idea until I realized `wait` and `wait_for` were just specializations of `wait_for_any`. This can probably be done with an

[issue18078] threading.Condition to allow notify on a specific waiter

Richard Oudkerk added the comment: > Furthermore, the complexity is rather bad: if T is the average number > of waiting threads, an C the number of conditions being waited on, the > wait is O(C) (appending to C wait queues) and wakeup is O(CT) (C > removal from a T-length deque). Which just mean

[issue18078] threading.Condition to allow notify on a specific waiter

João Bernardo added the comment: > I'm not convinced it's really useful. It doesn't seem a lot useful until you *really* need it. I've got 2 highly parallel programs that took advantage of this pattern. > the wait is O(C) (appending to C wait queues) and wakeup > is O(CT) (C removal from a T-

[issue18078] threading.Condition to allow notify on a specific waiter

Charles-François Natali added the comment: I'm not convinced it's really useful. Furthermore, the complexity is rather bad: if T is the average number of waiting threads, an C the number of conditions being waited on, the wait is O(C) (appending to C wait queues) and wakeup is O(CT) (C removal fr

[issue18078] threading.Condition to allow notify on a specific waiter

João Bernardo added the comment: Hi, This code is working quite well on my system, but I'm still not sure if the behavior of multiple predicates is the one other people want. So, for the thread start running again: - Should it test only the predicates from the awakened Conditions an accept if

[issue18078] threading.Condition to allow notify on a specific waiter

Changes by Raymond Hettinger : -- nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue18078] threading.Condition to allow notify on a specific waiter

João Bernardo added the comment: I did what @Richard Oudkerk said and created the "wait_for_any" classmethod for the Condition class. Other Changes: - I had to refactor "wait" and "wait_for" to be specializations of "wait_for_any". - try...except on "notify" because the inner lock might hav

[issue18078] threading.Condition to allow notify on a specific waiter

João Bernardo added the comment: > Condition.wait_for_any() would create a single inner lock and add it > to the _waiters list for each of the condition variables Now I see your point! Could it also have one (optional) argument so I can provide this lock myself? >while : >cond.wai

[issue18078] threading.Condition to allow notify on a specific waiter

Richard Oudkerk added the comment: > You cannot associate several conditions to the *inner lock*, because you > don't have access to them (otherwise I wouldn't open this issue). Condition.wait_for_any() would create a single inner lock and add it to the _waiters list for each of the condition

[issue18078] threading.Condition to allow notify on a specific waiter

João Bernardo added the comment: > It would be for waiting for several conditions associated with the > same lock, not for waiting for several locks. A Condition uses a 2 lock mechanism: - outer lock: one for all the waiters to access the Condition object - inner lock: one for each waiter

[issue18078] threading.Condition to allow notify on a specific waiter

Richard Oudkerk added the comment: > This could solve the waiting problem for the "thread", but also may > keep the other Condition objs waiting -- and that may not be problem > because I'm already using .notify_all() I don't understand what you mean. > Probably this function have more use ca

[issue18078] threading.Condition to allow notify on a specific waiter

João Bernardo added the comment: > But it might be nice to be able to wait on multiple conditions at > once, assuming they are associated with the same lock. Maybe we could > have a static method This could solve the waiting problem for the "thread", but also may keep the other Condition obj

[issue18078] threading.Condition to allow notify on a specific waiter

Richard Oudkerk added the comment: > BTW, I find .notify(N) not much useful, because the docs say it may wake > more threads on a different implementation and also I can't never know > whom am I waking. The fact that more than N threads can wake up is not a problem if you are retesting an app

[issue18078] threading.Condition to allow notify on a specific waiter

João Bernardo added the comment: I usually have hundreds of threads waiting on a single Condition object and I wake them with .notify_all() Sometimes, I want a specific thread to wake from this condition and finish their job apart from the others. The problem is that I have 2 "conditions" to

[issue18078] threading.Condition to allow notify on a specific waiter

Antoine Pitrou added the comment: I'm not sure what the point is. If you want to wake up a specific thread, you'd probably be better off with a dedicated per-thread synchronization primitive (either a Condition or something else). -- nosy: +neologix ___

[issue18078] threading.Condition to allow notify on a specific waiter

Changes by Serhiy Storchaka : -- nosy: +pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue18078] threading.Condition to allow notify on a specific waiter

New submission from João Bernardo: If users could provide an inner lock for `threading.Condition` acquire when making a thread wait, it would allow for notifying a specific waiter. Because of race conditions, using: cond.notify(1) may not wake the thread I want. Also, I may not want to wa