FeedaMail: Comments for Sutter’s Mill

	Comments for Sutter's Mill
	(Sponsor this newsletter) Comment on GotW #96: Oversharing by Bartosz Milewski These are good questions with some obvious and non-obvious answers. Obviously, having to worry about one more thing adds complexity and fragility to your code. But what is it specifically about mutable shared variables that makes them hard to manage? Two things come to mind: non-locality and non-determinism. Just like gotos, mutable variables introduce dependencies between remote parts of code. When you’re reading a shared variable you are seeing the result of a write that happened in any of the threads that have access to it. And the threads can interleave differently every time you run your program. That makes both reasoning and testing of concurrent programs orders of magnitude harder. When we write code, we usually have one or two scenarios of execution in mind; with concurrent code that number is just not realistic. I’ve seen people arguing that a certain combination of event cannot happen only because they eliminated the few scenarios of execution that came to their minds. But there were other (often rare) disastrous scenarios that didn’t cross their mind. In concurrent programming the scenario generator in our minds just cannot keep up. Read More » Comment on GotW #95 Solution: Thread Safety and Synchronization by Herb Sutter @mcmcc: I see where you’re coming from. In this case I did them in this order because “problem, then solution” seems to work better in general. In this case, it seemed like presenting “reduce sharing” would lead to incomplete answers (or “why?” questions) without being able to refer back to “data races and how bad they are” so I presented that first so I could refer to it. I’ll think about this and see if reversing the order makes sense for when these appear in book form. Read More » Comment on GotW #96: Oversharing by sbohmann @Bartosz true :) but what is in my opinion often underrated is that even in the absence of any kind of threads, shared mutable values can break a human mind’s limits of understanding the consequences of possible interference quite easily… Coroutines are just a classic example, but they are also not a precondition for creating mind-boggling complexity. Even in the simplest of purely procedural single-threaded programs without event loops driving coroutines etc. can you do that by modifying global variables. And shared mutable state has a lot in common with non-const global variables. The only basic difference is that you know for sure that such globals are visible and writable from everywhere, whereas in the case of shared mutable state, in the general case you must assume that they are visible and writable from anywhere, which isn’t much of a difference. But luckily, shared mutable state at least allows you to encapsulate it in a business logic that defines clear and concise rules for modification, thus artificially limiting your system’s complexity, which most of developing non-trivial systems is about after all :) Btw., @Herb, thanks for these wonderful questions, and I’m really looking forward to your answer! :) Read More » Comment on GotW #95 Solution: Thread Safety and Synchronization by ixache Herb, you wrote: “To make it possible for the code that uses a shared variable to so the above, two basic things must be true.” Is’nt there a lacking somewhere in that sentence ? Read More » Comment on GotW #95 Solution: Thread Safety and Synchronization by Herb Sutter @ixache: Aha, s/to so/to do/. Fixed, thanks. Read More »
	(Sponsor this newsletter)
	Delievered to you by Feedamail. Unsubscribe