Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #367

Re: C++0x, 29.3 p13 "[...] atomic stores visible [...] within a reasonable amount of time."

Show all headers | View raw

<moving away from comp.std.c++>

Joshua Maurice wrote:
> 
> 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.

C++11 aside (the latest draft is not public and I have no idea what it
says), on assembly level, in order to read the last value you need
read-modify-write operation such as fetch_add(0) and relaxed RMW reads
last value just fine. 

> 
> 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?

regards,
alexander.

Back to comp.programming.threads | Previous | Next — Next in thread | Find similar | Unroll thread

Thread

Re: C++0x, 29.3 p13 "[...] atomic stores visible [...] within a   reasonable amount of time." Alexander Terekhov <terekhov@web.de> - 2011-06-27 20:55 +0200
  Re: C++0x, 29.3 p13 "[...] atomic stores visible [...] within a reasonable amount of time." Joshua Maurice <joshuamaurice@gmail.com> - 2011-07-01 04:06 -0700
    Re: C++0x, 29.3 p13 "[...] atomic stores visible [...] within a  reasonable amount of time." Alexander Terekhov <terekhov@web.de> - 2011-07-01 17:35 +0200
      Re: C++0x, 29.3 p13 "[...] atomic stores visible [...] within a reasonable amount of time." Joshua Maurice <joshuamaurice@gmail.com> - 2011-07-01 15:23 -0700
        Re: C++0x, 29.3 p13 "[...] atomic stores visible [...] within a  reasonable amount of time." Alexander Terekhov <terekhov@web.de> - 2011-07-02 10:18 +0200
          Re: C++0x, 29.3 p13 "[...] atomic stores visible [...] within a reasonable amount of time." Joshua Maurice <joshuamaurice@gmail.com> - 2011-07-05 15:10 -0700
    Re: C++0x, 29.3 p13 "[...] atomic stores visible [...] within a reasonable amount of time." Edek <edek.pienkowski@gmail.com> - 2011-07-02 13:59 +0200
      Re: C++0x, 29.3 p13 "[...] atomic stores visible [...] within a  reasonableamount of time." Alexander Terekhov <terekhov@web.de> - 2011-07-05 10:12 +0200
        Re: C++0x, 29.3 p13 "[...] atomic stores visible [...] within a  reasonableamount of time." Edek <edek.pienkowski@gmail.com> - 2011-07-05 11:36 +0200

csiph-web