0

I have a Python object that is updated regularly, from an asynchronous I/O callback. A few threads need to wait for this object to be updated.

This "update" event is an instantaneous event, and as well the action of telling the waiting threads to wake up should be an atomic one.

I have looked for a few solutions:

  • Condition objects need you to acquire a lock first, which is a no-go: I need several threads to reach the wait unhindered, without fighting to acquire a lock.
  • Event objects generate a race condition: if a thread reaches the wait before the event is cleared, it won't wait, and on the contrary the event could be cleared before any thread is awoken.

The best solution would be an equivalent of the POSIX pause/kill combo, but for threads (at least the best that I can think of).

So, questions:

  • Does the pause/kill combo have an equivalent for Python 2.7 threads, and which one?
  • If not, what is the best compromise (in terms of reliability) for my use case, using the Python 2.7 standard library?

Here is something similar to what I would like to achieve:

# Would be a derived of threading.Event
# and the perfect solution for me, if it existed
ev = InstantEvent()

def update(*args):
    # do stuff with args
    ev.notifyAll()

if __name__ == "__main__":
    # do startup stuff
    ev.wait()
    # do more stuff

1 Answers1

0

each event can wait on Event object with wait() as you see. Even more: they can check periodically the event (wait with timeout) and then to do own job in the loop. Callback will set event when it done. You can combine several events by checking one then another, etc. I can not understand your problem. If you want exclusive reaction on event - use semaphore instead of event: to allow only one thread/listener to process callback completion. See more about Python threading: https://docs.python.org/3/library/threading.html

RandomB
  • 3,367
  • 19
  • 30