On Fri, Apr 11, 2014 at 11:15:14AM -0400, Chris Metcalf wrote: > It's unfortunate that you're rolling the fetch_or() unconditionally > out of cmpxchg(), since some architectures (like tilegx) do have > support for "fetchor" as a primitive atomic operation. Currently the > tilegx fetchor is only exposed to architecture-independent code via > set_bit() and test_and_set_bit(), but perhaps it's worth having an > atomic_or() in atomic.h so architectures can choose to optimize it?
Yeah, I know.. Linus hated atomic_or_return() -- which admittedly is a little worse than fetch_or, because the operation isn't reversible. Note that atomic_or_return() or rather, atomic_return_or() won't actually work here because thread_info::flags is not a fixed typed between archs, some have int, some have long. Then again, when I proposed that thing, I didn't have a usage for it. Still, Linus' main argument still holds, its a crappy primitive on x86 and one should not encourage its use by pretending its 'easy'. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
