Question

What is the reason for why is_lock_free requires an instance (it’s a member function)? Why not a metafunction of the type, or a static constexpr member function?

I am looking for an actual instance of why it is necessary.

Answer 1

The standard allows a type to be sometimes lock-free.

section 29.4 Lock-free property

The ATOMIC_…_LOCK_FREE macros indicate the lock-free property of the
corresponding atomic types, with the signed and unsigned variants
grouped together. The properties also apply to the corresponding
(partial) specializations of the atomic template. A value of 0
indicates that the types are never lock-free. A value of 1 indicates
that the types are sometimes lock-free. A value of 2 indicates that
the types are always lock-free.

The C++ atomic paper n2427 states the reason behind:

… The proposal provides run-time lock-free query functions rather
than compile-time constants because subsequent implementations of a
platform may upgrade locking operations with lock-free operations, so
it is common for systems to abstract such facilities behind dynamic
libraries, and we wish to leave that possiblility open. Furthermore,
we recommend that implementations without hardware atomic support use
that technique. …

And also (as Jesse Good pointed out):

The proposal provides lock-free query functions on individual objects rather than whole types to permit unavoidably misaligned atomic variables without penalizing the performance of aligned atomic variables