AtomicOrLocked: don't rely on std::is_trivially_copyable

[Al2Klimov]

It doesn't restrict data size which, however, matters for atomicness. E.g. long[7777777] is trivially copyable, but surely not lock-free, i.e. not worth using std::atomic.

[julianbrost]

i.e. not worth using std::atomic.

Why not?

Type alias for std::atomic<T> if the better choice, otherwise Locked<T> is used as a fallback.

And what makes Locked<T> the better choice?

[Al2Klimov]

not lock-free

... means it locks. Via a mutex, obviously.^{(1) (wall of text)} But we have one in Locked<>.

i.e. not worth using std::atomic.

(Or, to say it with a meme:

• "Uncle @Al2Klimov, can I have a mutex?"
• "We have a mutex at home."
• Mutex at home: Locked<>)

And what makes Locked<T> the better choice?

It guaranteed doesn't waste any std::atomic mutex pool which is very limited and designed for stuff that takes very few instructions to read/write. IMAO.

[julianbrost]

obviously^{https://chatgpt.com/share/6735cad5-d9c0-8004-a0b1-0c58064dd7fe}

Yeah, no, 10 pages of AI hallucination doesn't make something obvious.

It guaranteed doesn't waste any std::atomic mutex pool which is very limited and designed for stuff that takes very few instructions to read/write. IMAO.

Do we even have anything that uses std::atomic<T> with a sufficiently large T that this PR would even do something relevant? Or is this just a complete waste of time?

[Al2Klimov]

Do we even have anything that uses std::atomic<T> with a sufficiently large T

Nothing larger than void*, yet.

[Al2Klimov]

Actually, I wanted to make it perfect, but it didn't compile:

template <typename T>
using AtomicOrLockedBase = std::conditional_t<std::atomic<T>::is_always_lock_free, std::atomic<T>, Locked<T>>;

template <typename T>
using AtomicOrLocked = std::conditional_t<std::is_trivially_copyable_v<T>, AtomicOrLockedBase<T>, Locked<T>>;

error: _Atomic cannot be applied to type 'icinga::String' which is not trivially copyable