FeedaMail: Comments for Sutter’s Mill

	Comments for Sutter's Mill
	(Sponsor this newsletter) Comment on Reader Q&A: Is std::atomic_compare_exchange_* implementable? by nosenseetal @Anthony Williams is it a implementation or ISO bug? Read More » Comment on Reader Q&A: Is std::atomic_compare_exchange_* implementable? by nosenseeta; btw my apology, I thought it was just an another example of somebody not understanding some brainf**k atomic code, but it turns out to be about a serious bug. :D But since Herb said it is not I was like meh, boring… Read More » Comment on Reader Q&A: Is std::atomic_compare_exchange_* implementable? by Anthony Williams @nosenseetal It’s an implementation bug Read More » Comment on Reader Q&A: Is std::atomic_compare_exchange_* implementable? by Matthew Elvey Price Or rather… you guarantee it will NOT unexpectedly modified/invalidated. Whoops. Read More » Comment on Reader Q&A: Is std::atomic_compare_exchange_* implementable? by Matthew Elvey Price My reading of the standard is: part of 29.6.5/2: In the following operation definitions: — an A refers to one of the atomic types. — a C refers to its corresponding non-atomic type. (…) An example function definition from just before 29.6.5/20: bool atomic_compare_exchange_weak(A* object,C* expected,C desired) noexcept Expected is type C so is NOT atomic. If we assume what I’ve said above, the specific issue in your code is that by passing in a non-atomic variable (expected), you guarantee it will unexpectedly modified or invalidated during that call. Then you break that guarantee by deleting or modifying it in another thread. Ben’s code appears to account for this correctly. The compiler bugs listed only cover storing to expected in the success case where it would store the same value anyway. Read More » Comment on Reader Q&A: Is std::atomic_compare_exchange_* implementable? by Noob Learner In fact, I think Ducan is stretching the guarantee of atomicity to its function parameter which I don’t think was intended. Read More » Comment on Reader Q&A: Is std::atomic_compare_exchange_* implementable? by Noob Learner After reading both the SO as well as the above post. My initial reaction was that indeed Duncan and Anthony are both correct. However on second thoughts, I think Herb is also right. In this case for compare_exchange, I would rather say the atomicity was for the head node not for the node-next. Think of it this way suppose we have the following code which store the new value into the atomic_var and put the original value in the old_value. template void SuperStore(std::atomic& atmoic_var, const Ty1* new_value, Ty1* old_value); Obviously from the function signature, we safely say the the store to the atomic_var would be atomically safe, but to assume the write to old_value is safe would be a big no no. If it was atomic, old_value should have been std::atomic* old_value. I think to make the whole issue of compare_exchange better, ‘expected’ should have been an atomic variable. Or maybe the standard committee was referring to the atomicity of the calling object of compare_exchange_weak, rather than the atomicity of the compare_exchange_weak function parameters. It is just a guess and maybe I am wrong. Read More » Comment on Reader Q&A: Is std::atomic_compare_exchange_* implementable? by bames I don’t think the issue is that implementations are failing to make the assignment to expected atomic with the compare/exchange. The problem is that the spec guarantees that, if the exchange occurs, then expected is _not_ written to. Thus if the exchange occurs then another thread which was waiting on the exchange can go ahead and access expected, knowing that the compare_exchange will not write to it and there will therefore be no race. But since actual implementations write to expected unconditionally real implementations introduce a race. Read More » Comment on Reader Q&A: Is std::atomic_compare_exchange_* implementable? by Noob Learner My opinion on the issue is that the problem is not about race/unconditional write but more of sharing the ‘expected’ variable across thread. I would say there was never a guarantee in atomic write to ‘expected’. Thus I think trying to assume atomicity for ‘expected’ isn’t an appropriate thing. If there was never a guarantee to atomic write for ‘expected’ then we should not attempt to pass a variable to ‘expected’ which spans multiple thread. Think of it as a simple function: void foo(int* arg); In the above case, passing a variable to the function ‘arg’ which is shared across multiple thread is just asking for trouble. Whether function foo write arg unconditionally or does anything to it is beside the point. It doesn’t change the problem that passing in a variable used by multiple thread into arg is creating a problem of attempting atomicity/synchronisation on a variable/type not meant to do that. Read More » Comment on Reader Q&A: Is std::atomic_compare_exchange_* implementable? by Anthony Williams The write to expected does not need to be atomic. It should only be written to on failure, so if the compare-exchange succeeds, then other threads can touch the value passed as the “expected” parameter, because the compare-exchange will not do so (in a correct implementation). This is important when doing things like lock-free data structures, where the “expected” value may often be part of a node being added to the data structure by the compare-exchange. If the compare-exchange fails then the node is still not part of the data structure, so modifying expected is not a problem. If the compare-exchange succeeds then the node is now part of the data structure and may be accessed by other threads. Read More » Comment on Reader Q&A: Is std::atomic_compare_exchange_* implementable? by Herb Sutter BTW, I’ve started an email thread with the designers of the feature and Duncan and Anthony. I understood that the design of having compare_exchange_* take the “expected” value by reference, and update “expected” on failure to expose the old value, was only intended for convenience to simplify the calling loops which would otherwise always have to write an extra “reload” line of code. Now that “expected” is an lvalue, folks like Duncan are trying to use the success of compare_exchange_* to hand off ownership **of “expected” itself** to another thread. For that to be safe, if the compare_exchange_* succeeds then the thread that performed it must no longer read or write from “expected” else his technique contains a race. I don’t think this usage was ever intended to be supported, but I could be wrong (waiting to hear back from the feature’s designer), even if it wasn’t we may want to extend and add support for it now, and in any event I think we need to improve the standardese wording which is apparently unclear today. Read More »
	(Sponsor this newsletter)
	Delievered to you by Feedamail. Unsubscribe