Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
1  
There 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 Feb 18 at 18:46
1  
The 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 Feb 18 at 18:59
3  
If 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 Feb 18 at 19:31
1  
@mattnz What you're talking about is called the Dunning-Kruger effect and it is very real. –  Doval Feb 18 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 Feb 18 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.)

share|improve this answer
    
Wow, thanks for clarifying my misunderstanding of volatile in c#. –  Kelsie Feb 18 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 Feb 20 at 16:48

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.