The atomic notifying functions for `std::atomic_flag` are not always lock-free even though `std::atomic_flag` is specified to always be lock-free. Therefore, use of `std::atomic_flag::notify_one` or `std::atomic_flag::notify_all` may cause unpredictable behavior when called in a signal handler, even though the Standard currently claims that these functions are signal-safe. It would be useful for signal handlers to know for sure whether they can safely notify a `std::atomic_flag`. Therefore, I propose the introduction of member constant `is_notify_always_lock_free`, member function `is_notify_lock_free`, and free function `std::atomic_is_notify_lock_free` for `std::atomic_flag`. I also propose the same for `std::atomic` and `std::atomic_ref` specializations in case the lock-free property of their notifying functions differ from those of their other functions such as loads and stores. Similarly, in the case of the atomic waiting operations, it would be useful to know whether they are safe to call in signal handlers (despite not being lock-free), so analogous queries `is_wait_signal_safe` and so on are also proposed.