FeedaMail: Comments for Sutter’s Mill

	Comments for Sutter's Mill
	(Sponsor this newsletter) Comment on Reader Q&A: Acquire/release and sequential consistency by Herb Sutter @Fernando: That code is fine and needs no special code generation for many reasons (disjoint stacks so those locals won’t be adjacent; escape analysis and constant propagation would eliminate c and b outright; even if c and b were static and laid out adjacent in memory it’s fine because all modern processors have single-byte reads so no need even to inject alignment/padding, etc.). Ah, and now I see Bjarne already answered this right in that FAQ. :) Read More » Comment on Reader Q&A: Acquire/release and sequential consistency by Fernando Pelliccioni Hi Herb, I’ve seen the Atomics Weapons (1 and 2) videos, I found great, thanks! I have one doubt… In all examples where you explain the Memory Model you’re using atomic declarations, right? My question is: How C++11 protects us from case like the following? (Extracted from Bjarne FAQ – http://www.stroustrup.com/C++11FAQ.html#memory-model ) // thread 1: char c; c = 1; int x = c; // thread 2: char b; b = 1; int y = b; … “So, C++11 guarantees that no such problems occur for “separate memory locations.” More precisely: A memory location cannot be safely accessed by two threads without some form of locking unless they are both read accesses.” … Does this mean that a C++11 compliance compiler must insert “lock” instructions (barrier, fences, adquire/release, etc…) to protect NON-Shared NON-atomic memory? Or… is this solved assuming that there must be ‘Cache Coherency’ implementation? Or….the Standard imposes the existence of ‘Cache Coherency’? Thanks and regards, Fernando Pelliccioni, Read More »
	(Sponsor this newsletter)
	Delievered to you by Feedamail. Unsubscribe