I was told that atomic operations are a dynamic language feature. I was too afraid to ask in that context what this actually means because I didn't want my coworkers to think I'm stupid. But I actually don't really understand this statement.
My understanding of the term "atomic operations" is any operation that is either wholly executed or wholly not executed; you will definitely never be halfway through the operation when the thread context switches.
What does this have to do with dynamic vs static typing?
-
1There seems to be a lot of confusion here. A dynamic type system performs type checks at run time. A dynamic language generates or compiles code at run time. An atomic operation is an operation that can't be interrupted and therefore appears instantaneous to the rest of the system. These three features are completely unrelated and can be combined freely in the design of a programming language.amon– amon2014年02月18日 18:46:35 +00:00Commented Feb 18, 2014 at 18:46
-
1The context of the discussion was over drinks after a formal debate with a topic of "Static typing is better than dynamic typing." The argument that was being made by the person who said this is that even in the context of a language that is predominantly a statically typed language, there are dynamic features (such as reflection in c#). They made the claim that support for atomic operations is a dynamic feature.Kelsie– Kelsie2014年02月18日 18:59:02 +00:00Commented Feb 18, 2014 at 18:59
-
3If your co worker thinks you are stupid, hes living proof that they can always make a bigger idiot. A valuable lesson here is people are not always as skilled as they would like to think - and in my experience the lower the skills the more talk.mattnz– mattnz2014年02月18日 19:31:09 +00:00Commented Feb 18, 2014 at 19:31
-
1@mattnz What you're talking about is called the Dunning-Kruger effect and it is very real.Doval– Doval2014年02月18日 19:38:09 +00:00Commented Feb 18, 2014 at 19:38
-
1@Kelsie "They made the claim that support for atomic operations is a dynamic feature." They were wrong. And I offer exactly as much support for my assertion as they did for theirs :-)Ross Patterson– Ross Patterson2014年02月18日 23:07:12 +00:00Commented Feb 18, 2014 at 23:07
1 Answer 1
I was too afraid to ask in that context what this actually means because I didn't want my coworkers to think I'm stupid.
Actually, I think that asking questions is smart. It's how you learn things that you don't know. And in larger groups, it's likely that other people don't know it either, they're just afraid to ask too.
My understanding of the term "atomic operations" is any operation that is either wholly executed or wholly not executed ...
Yes, but that's only part of it. Another important part is that the operation appears to execute instantaneously, that is, you can never observe it in half-completed state. (Though the following part of the sentence indicates that that's what you meant.)
... such as in C# with the volatile keyword when setting or getting the value of a primitive, you will definitely never be halfway through getting or setting a volatile primitive when the thread context switches.
That's not what volatile
in C# is about. Setting the value of small primitive types (like int
, char
or reference, but not long
or double
) is always guaranteed to be atomic (see §5.5 Atomicity of variable references of the C# spec).
What volatile
is about is the order of accessing the fields (§10.5.3 Volatile fields of the spec). Normally, if you write something like:
this.value = 42;
this.valueIsSet = true;
and then observe it from another thread, then you could see valueIsSet
to be already true
and value
to be still 0
, due to compiler and processor optimizations that reorder instructions. With volatile
, such reordering is forbidden.
This also guarantees that the field is read every time, without volatile
a loop like
while (this.shouldRun)
{
// whatever; does not set this.shouldRun
}
might be compiled as:
if (this.shouldRun)
{
while (true)
{
// whatever; does not set this.shouldRun
}
}
In any case, using volatile
correctly is hard and you should avoid it unless you really need it for performance reasons. Most of the time, using locks and thread-safe library types is enough.
What does this have to do with dynamic vs static typing?
No idea. There certainly are non-trivial atomic operations in .Net (like those in the Interlocked
class).
The only thing I can think of is that some languages can use user-mode threads instead of native threads, and thus have more control over what operations are executed atomically, because it's the language runtime that decides when to switch threads. But that has nothing to do with dynamic or static typing. (And I have no idea if there are languages that actually take advantage of that.)
-
Wow, thanks for clarifying my misunderstanding of volatile in c#.Kelsie– Kelsie2014年02月18日 20:29:41 +00:00Commented Feb 18, 2014 at 20:29
-
@Kelsie: Your misunderstanding is very common. You might want to read my series of articles on this subject. It begins here: blogs.msdn.com/b/ericlippert/archive/2011/05/26/…, then blogs.msdn.com/b/ericlippert/archive/2011/05/31/…, then blogs.msdn.com/b/ericlippert/archive/2011/06/16/….Eric Lippert– Eric Lippert2014年02月20日 16:48:47 +00:00Commented Feb 20, 2014 at 16:48