FeedaMail: Comments for Sutter’s Mill

	Comments for Sutter's Mill
	(Sponsor this newsletter) Comment on GotW #95 Solution: Thread Safety and Synchronization by Herb Sutter @xiongzou: No, ints (and even chars) can get trashed in a race. Synchronization is not only about atomicity, it's also about ordering and disabling some optimizations. If you want a standalone mutable shared int that is safe to use concurrently from multiple threads, it must be at least an atomic or part of data protected by a mutex. Otherwise, in a data race even an int can get trashed, such as by an optimizer that thinks only its thread is using the int and performs normal legal single-threaded optimizations, such as injecting speculative writes which in a race could cause other threads to see “impossible” values. Read More » Comment on GotW #96: Oversharing by Michael Golub 1. a. Increased ratio between boilerplate code and actual logic makes code more complex. 1. b. If boilerplate code is forgotten problem is not seen immediately. Such buggy code will compile and pass unit tests. 1. c. With example as-is we can not have multiple readers simultaneously. If shared object is overly large (bad design anyway) with independently modifiable members we have sub-optimal lock granularity. 2. It requires a change in algorithm that uses shared object. If algorithm relies on sharing and modification to work data should be physically shared and modifiable. Or algorithm that works on once shared data must be changed. 3. Make shared object internally synchronized. Mark methods that modify shared data as const. Thanks to knowledge of internal structure may be more efficient. Can be hard to implement in practice. Read More » Comment on GotW #95 Solution: Thread Safety and Synchronization by xiongzou I am a bit confused, in most modern CPUs, atomic operation is guranteed on a word size memory with read and write operations. int is a word size in most operating systems, which should be safe from race condition in your example, right? Not sure I mis-understand anything here? Thanks Read More » Comment on GotW #95 Solution: Thread Safety and Synchronization by Bartosz Milewski @xiongzou: Atomic operations also guarantee ordering: all threads see changes to atomic variables in the same order (it’s called sequential consistency and is only guaranteed for strong atomics). A simple example of a race is when a thread modifies one shared variable “x” and then sets a shared flag “done.” You want other threads to see those writes in the same order, because if they see “done” before the modification to “x”, they will work with stale data. This is *not* guaranteed if the flag is not atomic. The compiler is free to reorder writes to different variables, and the processor is free to hold some writes in local buffers before committing them to global memory. So atomic variables are not only about atomicity but also about visibility. Read More »
	(Sponsor this newsletter)
	Delievered to you by Feedamail. Unsubscribe