During racy initialization, a race can happen where a notification is dropped

[notgull]

The following logic exists in notify:

https://github.com/smol-rs/event-listener/blob/fdbe437699680bb5e402bc89aa2a0dd12a1ebc25/src/lib.rs#L440

The intent is to make it so notifying an Event that has never has an EventListener is a single atomic operation and nothing else. However, a race condition can happen here where a notification is dropped even when there is a listener available.

• Thread 0 calls listen(). As part of listen() the inner() function is called, which allocates the Arc<Inner> and compare_exchanges it into the inner pointer.
• However, between the load of the inner pointer and the final compare_exchange, Thread 0 is pre-empted and Thread 1 starts.
• Thread 1 calls notify, which then calls try_inner, which loads the inner pointer. Since it hasn't been updated yet this returns 0, which the notify function interprets as the event not listening yet.
• Thread 1 finished notify by notifying no listeners.

If Thread 0 pre-empted Thread 1 while Thread 1 was updating some atomic state, this can lead to a deadlock.

[notgull]

It seems like this can also happen with the needs_notification optimization under loom's model.

[notgull]

MIRI tests on async-lock pass with #139, so it looks like this is the underlying issue for https://github.com/smol-rs/event-listener/issues/123