classification
Title: clear() should return prior state in threading.Event
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.7
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: jmoy, rhettinger, serhiy.storchaka, tim.peters
Priority: low Keywords:

Created on 2017-02-05 07:37 by jmoy, last changed 2017-02-09 16:24 by jmoy. This issue is now closed.

Messages (6)
msg287039 - (view) Author: Jyotirmoy Bhattacharya (jmoy) * Date: 2017-02-05 07:37
The clear() method for Event objects currently does not return anything.

It would be useful to have it return the state of the Event prior to it being cleared.

This would be useful since multiple threads may wake up from an event at the same time and all may try to clear() the event. A return value from clear will indicate to a thread if it won the race to clear the event.
msg287097 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2017-02-06 08:05
> A return value from clear will indicate to a thread if it 
> won the race to clear the event.

Why would we care who won the race to clear? I would think that the important thing is that the event is cleared, not who did it.
msg287108 - (view) Author: Jyotirmoy Bhattacharya (jmoy) * Date: 2017-02-06 08:56
> > A return value from clear will indicate to a thread if it
> > won the race to clear the event.
>
> Why would we care who won the race to clear? I would think that the
> important thing is that the event is cleared, not who did it.
>

Here's the scenario that prompted my report: the Event is set to indicate
that certain 'work' has accumulated and one among a pool of workers uses
clear() to claim the work accumulated till that point. If clear() returned
a value, we could easily ensure that only one among the workers woken up
actually does the work.

Of course, in this case it would be more efficient to wake up just one
worker using a Condition object and notify() but then one has to write the
logic to maintain the state of the event. An Event whose clear() returned a
value would allow for a quick and dirty solution.
msg287109 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-02-06 09:00
> A return value from clear will indicate to a thread if it won the race to clear the event.

I think other synchronization primitives should be used for this. I'm not sure that other implementations of Event (e.g. multiprocessing.Event) can efficiently return the previous state.
msg287275 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2017-02-08 05:04
I can't judge a use case for a thread gimmick in the absence of wholly specified examples.  There are too many possible subtleties.  Indeed, if I'd do anything with Event.clear() it would be to remove it - I've seen too much code that suffers subtle race bugs when trying to reset an event.  The one thing it's clearly good for is announcing a one-time global state change, for which it's sufficient, efficient, clear, and hard to get wrong.

Can you use a Barrier instead?  The Barrier design allows reuse with no special care, Barrier.wait() already returns a little integer unique to each thread, and the Barrier constructor even allows a function to be passed in to be executed by (exactly) one of the threads when the Barrier is complete.
msg287435 - (view) Author: Jyotirmoy Bhattacharya (jmoy) * Date: 2017-02-09 16:24
Thanks for the comments above. I'm going to rethink my design. Closing this bug.
History
Date User Action Args
2017-02-09 16:24:10jmoysetstatus: open -> closed
resolution: not a bug
messages: + msg287435

stage: resolved
2017-02-08 05:04:57tim.peterssetmessages: + msg287275
2017-02-07 03:04:16rhettingersetnosy: + tim.peters
2017-02-06 09:00:11serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg287109
2017-02-06 08:56:19jmoysetmessages: + msg287108
2017-02-06 08:05:47rhettingersetpriority: normal -> low
nosy: + rhettinger
messages: + msg287097

2017-02-05 07:37:48jmoycreate