I have a question regarding C++0x, 29.3 p13. In draft n3242, the exact
text is:

"Implementations should make atomic stores visible to atomic loads
within a reasonable amount of time."

I am wondering if there is a well known intent as to the meaning of
"reasonable". Allow me to explain. I apologize up front if I'm
mistaken in any of my understandings, and please point out any such
misunderstandings. I also understand this is a QoI issue, but I think
that this particular answer greatly affects how one should write
portable code, which is why it's not quite something we ought to be
allowed to handwave as "implementation defined".

Consider:
   std::atomic<int> x;
   //...
   while(x.load(std::memory_order_relaxed)) {}
That is, suppose we have an atomic variable x, and perhaps
specifically the type which is guaranteed to be lock-free. (I can't
quite find the text for that offhand.) It's my understanding that the
intent is for that load to be implemented by whatever passes for the
normal, common assembly load on that platform.

So, that simple assembly load may be satisfied by a core local cache.
If it is satisfied by a core-local cache, then the changes are high in
that busy waiting loop that future loads will be satisfied by a core
local cache, and thus it may not see a new write, ever, barring other
things. Other things, such as the common multi-tasking, preemptive
threading, OS. For that, eventually that busy loop will exhaust the
thread's timeslice, and it will be taken off the core. At some later
point, it will be put back on the core, which as I understand commonly
invalidates any core local caches, which means that the next load of
that busy waiting loop will go to main memory (or non-core local
cache, etc.), and it will see a new value.

So, would such an implementation be "conforming in spirit"? I
understand this is a QoI issue, but it is relevant. Specifically, is
there some understood intent and meaning that "reasonable" means
"maybe the next time the thread is scheduled out and scheduled back
in", or is "reasonable" meant to be something sooner than that?

This may be relevant to real world code for cooperative thread
cancelling. I assume the default way of handling cooperative thread
cancelling is to have a lock-free std::atomic bool variable which is
global to the "job" which can be cancelled. Call that the "stop flag".
Threads doing the jobs will periodically check the stop flag, and if
read true, then they will bail out and end the job. The question is
whether the stop flag should use memory_order_relaxed loads and stores
or seq_cst loads and stores. If relaxed loads and stores can be
delayed until the thread is scheduled out and back in, then that may
be too high of a delay for responsive cooperative job cancellation.
It's my understanding that with seq_cst loads and stores to the stop
flag, then that cannot be delayed by anything more than a "few"
assembly instructions, due to the total order S.

Of course, in practice, on "normal desktop processors", for non-
trivial code aka code which isn't just a busy waiting loop like above,
I expect that the caches will eventually get flushed, probably usually
much before a thread exhausts its timeslice, so the above reasoning is
rare worst case scenario. Perhaps it's still practical to use relaxed
loads and stores for the stop flag, despite the low probability
possibility that the stop flag may be delayed a very long time?

Then again, what about more exotic architectures, like NUMA
processors? How would that interact with this? I am woefully ignorant
on such details, and that is why I ask. Does C++0x, 29.3 p13 require
some intelligence from the compiler so that the compiler must
implement relaxed loads and stores as something more than the simple
assembly loads and stores? Perhaps most are simple assembly loads and
stores, but the compiler puts whatever assembly magic in loops and
here and there to fulfill the "within reasonable amount of time"
guarantee?


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]