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

Groups > comp.programming.threads > #377

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

Show all headers | View raw

Joshua Maurice wrote:
[...]
> >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.
> 
> True. After I wrote that, I considered that using atomic RMW is
> another option. It seems using relaxed writes and reads for a stop
> flag is a bad idea. I'd guess that an atomic RMW operation with

Relaxed write is just fine (if you don't want to communicate some state
to the to-be-stopped thread(s), if you do want it then release write is
what you need). 

fetch_add(0) (relaxed or acquire) RMW is meant to read the flag, not
write.

> std::memory_order_relaxed would translate into a "cheaper" or as cheap
> as operation than a read with std::memory_order_seqcst, as the RMW
> only needs to synchronize on that single memory location.

RMW is needed to observe the last value within duration of RMW
instruction. 

OTOH seqcst read may yield 'old' value for "a reasonable amount of time"
just like relaxed read. 

> 
> I'm wondering what people do in practice on this, besides using a
> mutex. They use RMW operations for the "set" of the stop flag and all
> "tests" of the stop flag?

Most people are mostly wrong. :-) You might want to check various
implementations of lock-free sem_getvalue()/GETVAL for use of fully
fenced RMW to read the semaphore value.

> 
> Also, AFAIK, when using the C++0x "interface" for RMW operations, you
> need to write a value. Thus, each thread when testing the stop flag

fetch_add(0) simply writes old value. Think of x86 LOCK XADD(0).

> would write 0 with a RMW, and if it read 1 with that RMW, then it
> would have to reset the stop flag for the benefit of other threads
> (and other tests later in this thread). I'm wondering if there is some
> sort of C++0x primitive that is an atomic test-and-set. I failed to
> notice one, but I haven't exactly read the entire thing thoroughly
> either.

Search the entire thing for "atomics.flag".

regards,
alexander.

Back to comp.programming.threads | Previous | Next — Previous in thread | 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