Implementing atomic<T>::store

Question

I'm attempting to implement the atomic library from the C++0x draft. Specifically, I'm implementing §29.6/8, the store method:

template <typename T>
void atomic<T>::store(T pDesired, memory_order pOrder = memory_order_seq_cst);

The requirement states:

The order argument shall not be memory_order_consume, memory_order_acquire, nor memory_order_acq_rel.

I'm not sure what to do if it is one of these. Should I do nothing, throw an exception, get undefined behavior, or do something else?

_{P.S.: "C++0X" looks kinda like a dead fish :3}

Answer 1

Do what you want. It doesn't matter.

When ISO state that you "shall not do something", doing it is undefined behaviour. I would opt for whatever makes your implementation "better" (in your eyes, be that faster, more readable, subject to the principle of least astonishment, and so forth).

Myself, I'd go for readability (since I would have to maintain the thing) with speed taking a close second.

Answer 2

I'd rather get vaguey sane behaviour that something crazy.

Well, as a potential consumer of your library, here's what I'd like: if there's no performance cost to the documented usage, then see if one of the memory_order values provides a functional superset of the others, particularly something corresponding to what a caller might naively expect the unsupported modes to do (if any sensible expectation can be formed). The caller may get the slowest, safest mode, but that's better than something functionally wrong. You minimise the client code's dependency on getting everything perfect for your code. The problem with this - compared to an assert/exception - is that it can go unnoticed in a test environment, so consider also writing an explanation to std::cerr, using a static variable to limit the messages to one per process run. That's a very useful diagnostic.

An exception, fatal assertion etc. might bring down a client application at a very inconvenient moment.... Seems a bit draconian, and not something I'd appreciate particularly. Another option is to have an environment variable control this behaviour.

(There's presumably a similar issue for values that aren't even in your current enumeration.)

Answer 3

I prefer a compile time error. If not that, then an assert() failure.

Assert is good because it compiles out of the release version and will not impact performance.

Compile time errors are even better because they provide more immediate feedback without waiting for the software to trip over the bug. Compile time error checks are a thing I love about C++ code over Python, Ruby, Perl code.