| Home | Forums | Reviews | Guides | Newsgroups | Register | Search |
 |
| Thread Tools |
|
Guest
Posts: n/a
|
|
|
|
||
|
|
| |
|
Guest
Posts: n/a
|
|
|
|
|
||
|
|
| |
|
Guest
Posts: n/a
|
|
|
|
|
||
|
Guest
Posts: n/a
|
|
|
|
|
||
|
Guest
Posts: n/a
|
On 2 อมส, 15:11, Anthony Williams <anthony_w....@yahoo.com> wrote:
> > Ok. Thank you. So memory_order_acq_rel is what usually called "full > > fence" (mfence on x86). And memory_order_seq_cst also enforces total > > order between *all* modifications in the system (locked instruction on > > x86). > > x86 is a bad architecture to use for examples, since there are too many > implicit fences, but I think you understand. I hope  > It is also worth noting that seq_cst only enforces a total order of seq_cst > operations: relaxed operations are still unordered, and a seq_cst operation is > treated as acq_rel by any other acquire/release/acq_rel operations. > > > Hmmm... Now I am trying to figure out when memory_order_acq_rel is > > insufficient, and one need memory_order_seq_cst. I can't imagine any > > example straight off. But there must be some substantial reasons for > > inclusion memory_order_seq_cst into standard. Can you provide some > > example with memory_order_seq_cst? > > seq_cst is included, and is the default, because it is easiest to reason > about. If you looked at my slides, many people will find slide 11 hard to deal > with: the two reader threads see different orders of events. > > Atomic ops are hard anyway, but non-SC atomics are an order of magnitude > harder. I agree that CS is much easier to reason about because it's like interleaving of all operations. But, in my opinion, it's... strange reason for inclusion into standard... there must be at least some use cases for CS... I think that situation on slide 11 is quite... unrealistic. Well, not situation is unrealistic. Unrealistic that mentioned output can break some real algorithm. Or I'm not right? I'm trying to figure out some use cases for CS... So reasoning of WG21 is "Use seq_cst until you don't understand slide 11 of Anthony Williams' Presentation. Then forget about seq_cst and use acq_rel" Dmitriy V'jukov |
|
|
|
|
|||
|
Guest
Posts: n/a
|
|
|
|
|
||
|
Guest
Posts: n/a
|
"Dmitriy V'jukov" <> writes:
> On 2 อมส, 15:11, Anthony Williams <anthony_w....@yahoo.com> wrote: > >> > Ok. Thank you. So memory_order_acq_rel is what usually called "full >> > fence" (mfence on x86). And memory_order_seq_cst also enforces total >> > order between *all* modifications in the system (locked instruction on >> > x86). >> >> x86 is a bad architecture to use for examples, since there are too many >> implicit fences, but I think you understand. > > I hope > >> It is also worth noting that seq_cst only enforces a total order of seq_cst >> operations: relaxed operations are still unordered, and a seq_cst operation is >> treated as acq_rel by any other acquire/release/acq_rel operations. >> >> > Hmmm... Now I am trying to figure out when memory_order_acq_rel is >> > insufficient, and one need memory_order_seq_cst. I can't imagine any >> > example straight off. But there must be some substantial reasons for >> > inclusion memory_order_seq_cst into standard. Can you provide some >> > example with memory_order_seq_cst? >> >> seq_cst is included, and is the default, because it is easiest to reason >> about. If you looked at my slides, many people will find slide 11 hard to deal >> with: the two reader threads see different orders of events. >> >> Atomic ops are hard anyway, but non-SC atomics are an order of magnitude >> harder. > > > I agree that CS is much easier to reason about because it's like > interleaving of all operations. But, in my opinion, it's... strange > reason for inclusion into standard... there must be at least some use > cases for CS... I think that providing a layer that is easier to reason about *is* a good use case. It is also the same level of guarantee provided by the Java 1.5 memory model in the absence of data races, if I understand correctly. http://java.sun.com/docs/books/jls/t...ml/memory.html > I think that situation on slide 11 is quite... unrealistic. Well, not > situation is unrealistic. Unrealistic that mentioned output can break > some real algorithm. Or I'm not right? I'm trying to figure out some > use cases for CS... Non-SC atomics can be very hard to use correctly. The members of the memory model group (of which I'm only a peripheral member) have had long discussions about the meaning of several examples. If the experts have to have long discussions, we need a simpler layer. > So reasoning of WG21 is "Use seq_cst until you don't understand slide > 11 of Anthony Williams' Presentation. Then forget about seq_cst and > use acq_rel"  That's the simplest example I could think of to demonstrate the point. The consequences can be quite far-reaching, though, especially if you have other threads in the mix. You're currently working on lock-free stuff, so you should be well-aware of that. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL |
|
|
|
|
|||
|
Guest
Posts: n/a
|
|
|
|
|
||
|
Guest
Posts: n/a
|
|
|
|
|
||
|
Guest
Posts: n/a
|
|
|
|
|
||
|
|
| |
|
| Thread Tools | |
|
|
