Atomicity, volatility and immutability are different, part three

So what does “volatile” mean, anyway? Misinformation abounds on this subject. First off, so as to not bury the lead: in C# the rules have been carefully designed so that every volatile field read and write is also atomic. (Of course the converse does not follow; it is perfectly legal for an operation to be…

18

Atomicity, volatility and immutability are different, part two

Last time we established that an “atomic” read or write of a variable means that in multithreaded scenarios, you never end up with “halfway mutated” values in the variable. The variable goes from unmutated to mutated directly, with no intervening state. I also talked a bit about how making fields of a struct “readonly” has…

8

Atomicity, volatility and immutability are different, part one

I get a fair number of questions about atomicity, volatility, thread safety, immutability and the like; the questions illustrate a lot of confusion on these topics. Let’s take a step back and examine each of these ideas to see what the differences are between them. First off, what do we mean by “atomic”? From the…

23

Read-only and threadsafe are different

Here’s a common problem that we face in the compiler realm all the time: you want to make an efficient immutable lookup table for mapping names to “symbols”. This is in a sense the primary problem that the compiler has to solve; someone says “x = y + z;” and we have to figure out…

15

Careful with that axe, part two: What about exceptions?

(This is part two of a two-part series on  the dangers of aborting a thread. Part one is here.) Suppose you’re shutting down the worker thread we were talking about last time, and it throws an exception? What happens? Badness, that’s what. What to do about it? As in our previous discussion, it is better…

10

Careful with that axe, part one: Should I specify a timeout?

(This is part one of a two-part series on the dangers of aborting a thread. Part two is here.) The other day, six years ago, I was was talking a bit about how to decide whether to keep waiting for a bus, or to give up and walk. It led to a quite interesting discussion…

19

What is this thing you call "thread safe"?

Caveat: I am not an expert on multi-threading programming. In fact, I wouldn’t even say that I am competent at it. My whole career, I’ve needed to write code to spin up a secondary worker thread probably less than half a dozen times. So take everything I say on the subject with some skepticism. A…

30

Events and Races

Here’s a question similar to one I saw on stackoverflow the other day. Suppose you have an event: public event Action Foo; The standard pattern for firing this event is: Action temp = Foo;if (temp != null)      temp(); What the heck is up with that? Why not just call “Foo()” ? First off, this pattern…

30

Locks and exceptions do not mix

A couple years ago I wrote a bit about how our codegen for the lock statement could sometimes lead to situations in which an unoptimized build had different potential deadlocks than an optimized build of the same source code. This is unfortunate, so we’ve fixed that for C# 4.0. However, all is still not rainbows,…

39

Arrays considered somewhat harmful

I got a moral question from an author of programming language textbooks the other day requesting my opinions on whether or not beginner programmers should be taught how to use arrays. Rather than actually answer that question, I gave him a long list of my opinions about arrays, how I use arrays, how we expect arrays to be…

63