FeedaMail: Comments for Sutter’s Mill

	Comments for Sutter's Mill
	(Sponsor this newsletter) Comment on GotW #89 Solution: Smart Pointers by J. J. Lee Is there any helper template to relieve pain from make_unique to make_shared, if I decide to change from unique_ptr to shared_ptr later? For example, template <class SP> class smart_ptr_switch { template <class... Args> static SP make_smart(Args&&... args) { if (SP is some kind of unique_ptr<T>) { return std::make_unique<T>(new T(std::forward<Args>(args)...)); } else if (SP is some kind of shared_ptr<T>) { return std::make_shared<T>(new T(std::forward<Args>(args)...)); } else { static_assert ??? } } }; So I can typedef my_smart_pointer to a std::unique_ptr first. If later I change typedef my_smart_pointer to a std::shared_ptr, I don’t need to change all std::make_unque to std::make_shared. If I call smart_ptr_switch::make_smart(…) and typedef std::unique_ptr my_smart_pointer, this method will return a result from make_unique. If I call smart_ptr_switch::make_smart(…) and typedef std::shared_ptr my_smart_pointer, this method will return a result from make_shared. Read More » Comment on GotW #93 Solution: Auto Variables, Part 2 by Auto Pilot | LightSleeper […] For even more recommendations on why auto is a good idea (efficiency, guaranteed initialization, and correctness), see Herb’s GotW #93. […] Read More »
	(Sponsor this newsletter)
	Delievered to you by Feedamail. Unsubscribe

FeedaMail: Comments for Sutter’s Mill

	Comments for Sutter's Mill
	(Sponsor this newsletter) Comment on GotW #91: Smart Pointer Parameters by C++的未来和指针 | 闻之山 […] Sutter写了一篇非常好的文章:《GotW about this in May》。Eric Niebler 在他的Meeting […] Read More »
	(Sponsor this newsletter)
	Delievered to you by Feedamail. Unsubscribe

FeedaMail: Comments for Sutter’s Mill

	Comments for Sutter's Mill
	(Sponsor this newsletter) Comment on GotW #95 Solution: Thread Safety and Synchronization by Dan can anyone give a reproducible code example for int getting trashed in race, if all threads use this variable as int type? Read More »
	(Sponsor this newsletter)
	Delievered to you by Feedamail. Unsubscribe

FeedaMail: Comments for Sutter’s Mill

	Comments for Sutter's Mill
	(Sponsor this newsletter) Comment on GotW #89 Solution: Smart Pointers by Rob Stewart @Marco You are correct that the block cannot be released until the last shared_ptr/weak_ptr is destroyed. However, the object’s destructor is invoked when the last shared_ptr is destroyed. Read More »
	(Sponsor this newsletter)
	Delievered to you by Feedamail. Unsubscribe

FeedaMail: Comments for Sutter’s Mill

	Comments for Sutter's Mill
	(Sponsor this newsletter) Comment on GotW #95 Solution: Thread Safety and Synchronization by Bartosz Milewski @xingzou: It’s very unfortunate that Java and C++ gave the word volatile completely different meanings. In Java, volatile would indeed protect you from a race, in C++ it would do no such thing. Think of Java volatile == C++ atomic. Think of C++ volatile as a way of accessing memory mapped IO. Read More »
	(Sponsor this newsletter)
	Delievered to you by Feedamail. Unsubscribe

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 GotW95: Thread Safety and Synchronisation | musingstudio […] article on thread safety and synchronisation from Herb […] Read More » Comment on GotW #95 Solution: Thread Safety and Synchronization by xiongzou Thanks a lot for your clarifications. It does help a lot! To go further on the question, if we declare the int volatile, will a “volatile int” free from race condition? Assume the compiler and CPU supports volatile. Thanks & regards Read More »
	(Sponsor this newsletter)
	Delievered to you by Feedamail. Unsubscribe

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

FeedaMail: Comments for Sutter’s Mill

	Comments for Sutter's Mill
	(Sponsor this newsletter) Comment on GotW #96: Oversharing by Bartosz Milewski Question 2. Except for trivial cases, data has to be passed between threads. There are many ways to do it and some of them don’t require additional synchronization. I’m saying “additional” because there are two synchronization points in the life of every thread: its creation and its destruction. So you can create data before you pass it to the thread constructor and, if you can guarantee that you won’t access it afterwards, the thread is free to use it without synchronization. Similarly, a thread may create and manipulate data before it returns it (e.g., through a future) to the caller. The best guarantee of non-access is provided by move semantics. When you move your data to the constructor of the thread, or move it back from the thread, you are guaranteed that there is only one thread at a time that can access it. Another way to avoid synchronization is to use immutable data. In that case many threads may access the same data concurrently without synchronization. You have to make sure though that the data was created before the threads were started (or there is some other “happens before” edge between creation and use), because data creation almost always involves mutation. Read More » Comment on GotW #96: Oversharing by Bartosz Milewski Question 3. If the variable is not physically shared, then threads won’t be able to see each other’s writes. But if that’s okay, then you can give each thread its own private copy to read and modify and then, at a later time, collect the results and merge them, a la map/reduce. Is that what you had in mind? Read More » Comment on GotW #95 Solution: Thread Safety and Synchronization by Paul Groke Hi Herb, what do you mean by “concurrent const operations that are just reading from the same variable x must be safe”? That all const operations that are logically a clean “read” must be safe? I’m not sure that that’s a good definition. On the one hand, it’s more complicated than it has to be. After all, what kind of const operations can (or should) be there that are not logically a clean “read”? So wouldn’t it be better to just say all const operations? On the other hand it forbids stuff like lazy evaluation. So for me this is somewhere in between “restrictive, but so simple that anyone can understand it and apply it correctly without having to think too much” and “a little complicated but allows us to do cool stuff that we otherwise couldn’t”. So maybe the best thing would be to just document which methods are thread-safe and which are not. Read More » Comment on GotW #96: Oversharing by duhonedd 1) The primary problem is that it is too easy for a user of some_obj to forget, or not even realize that synchronization is required. Especially as a program gets very large. some_obj will be relying on a comment that programmers won’t read to inform them that synchronization is needed. On the plus side, by not embedding synchronization into some_obj’s class, you wont have to pay for it if you don’t need it on some_obj2. 2, 3) The main goal is to make sure users can’t accidently use a shared object without synchronization, and hopefully to at the same time not require it if another instance is used strictly internally somewhere that is already internally synchronized. It would also be nice if the maintainer of the class of some_obj didn’t have to think about synchronization, keep concerns separated. For this I like the handle body idiom. No classes provide synchronization directly, instead a family of thread safe handles can be used to wrap an instance in, when needed. We can also make use of this handle to cleanly synchronize when we need to make multiple calls to some_obj atomicly. Code is below. template&lttypename T&gt class Shared { public: void Lock(std::function&ltvoid (T& _instance)&gt _work) { std::lock_guard&ltstd::mutex7gt lock(m_mutex); _work(m_instance); } private: std::mutex m_mutex; T m_instance; }; Shared&ltFoo&gt some_obj; some_obj.Lock([](auto _instance){ _instance.foo1(); _instance.foo2(); }); Read More »
	(Sponsor this newsletter)
	Delievered to you by Feedamail. Unsubscribe