alt Hacker NewsWhat was the disagreement on the atomics issue?
I only know them from openMP (more of a Fortran person)… without much thought my gut says that it’d be possible to implement an atomic operation with a mutex, but sort of defeating the purpose. An atomic operation is mostly expected (intended? hoped?) to be backed by some hardware atomic instructions anyway, right?
They insisted that it wasn't legally possible and no one would ever do that, but std::atomic<T>::is_lock_free [0] exists precisely because implementers were doing it. The only case that anyone was ever likely to encounter AFAIK was atomic structs >= 16 bytes on MSVC because they couldn't use cmpxchg16b for reasons.
I had been using a truly awful stdlib on an embedded platform whose implementers saw that freedom as a license to implement all atomics with mutexes. I assume it was because they couldn't be bothered to write new implementations for every platform they supported, so they'd write the basic primitives and got the rest of the implementation "for free". This isn't even close to the dumbest decision they made.
Obviously that wasn't acceptable for any real use, so I wrote up a better implementation, sent it to the vendor as a patch to save their other poor customers the effort, and used it as a one line example in a larger list on my resume that the interviewer seized on. It's not uncommon for a FAANG interview to be adversarial like that.
[0] https://en.cppreference.com/cpp/atomic/atomic/is_lock_free