Cooperatively pausing async methods

re: Cooperatively pausing async methods

jods — Tue, 28 May 2013 10:30:03 GMT

Note: there have been several questions on StackOverflow regarding the MSDN article and specficially the read introducion section, e.g.:

stackoverflow.com/.../16789697

stackoverflow.com/.../read-introduction-in-c-sharp-how-to-protect-against-it

Maybe it's best to end this discussion there.

re: Cooperatively pausing async methods

jods — Fri, 24 May 2013 09:59:23 GMT

@Igor, Stephen:

Sorry to come again on this topic but I was surprised when reading the MSDN Magazine (Oct 05) article 'Understand the Impact of Low-Lock Techniques in Multithreaded Apps'.

When describing the .net 2.0 memory model, it explicitely says:

"Reads and writes cannot be introduced"

Which seems to be the exact opposite of Igor's statement in his article.

I also found that Joe Duffy makes the same statement in his book "Concurrent Programming on Windows", pp517-8:

"the .NET memory model prohibits it [read introduction] for ordinary variables referring to GC heap memory".

So what should I conclude here?

1. The memory model was weaken in .net 4? (unlikely I guess)

2. The JIT optimizations may violate the CLR memory model? (which would be very dangerous)

3. Igor's article is incorrect about read introductions?

4. Joe Duffy and Vance Morrisson are mistaken about read introductions?

Thanks!

re: Cooperatively pausing async methods

jods — Wed, 15 May 2013 21:48:08 GMT

Thanks Igor!

I read that section (§3.10 Execution Order) before but completely missed this important aspect: volatile reads and writes are side-effect.

Hence they can't be introduced or removed!

That explains it everything.

Just to be sure that I understood your answer about MemoryBarrier: introducing a read can be seen as moving a memory operation accross the barrier and this is why it's forbidden, even though it's not a side-effect if the variable is not volatile? E.g.

var cur = memory_read;

Thread.MemoryBarrier();

// Accessing memory_read here is moving a memory operation accross the barrier?

return cur != null ? cur.IsPaused : false;

Of course Interlocked or Thread.VolatileRead are more obvious as they can't be "repeated" or "introduced".

Thanks for the explanation!

re: Cooperatively pausing async methods

Igor Ostrovsky - MSFT — Wed, 15 May 2013 20:49:44 GMT

@jods: The reason I mentioned the "Publication via Volatile Field" section is that it describes how to safely use volatile fields. For example, the WaitWhilePausedAsync method in this article is an instance of the Publication via Volatile Fields pattern. Also take a look at the "Lazy Initialization" pattern.

> Can you explain which rule above has been broken if "cur" in the expression "cur.Task" is read from m_paused again rather than from a temporary?

Elsewhere in the C# specification, a volatile read is defined to be a "side effect". As a result, repeating the read of m_paused would be equivalent to adding another side effect, which is not allowed.

> Bonus chatter: how does all this relate to non-volatile variable? What if I rely on a few MemoryBarrier or Interlocked operations rather than an always volatile field?

That can work too.

re: Cooperatively pausing async methods

jods — Wed, 15 May 2013 20:21:48 GMT

@Igor: I read it again and it doesn't explicitely talk about "Read introductions" only reorderings.

The rule "no read is introduced that would break semantics of a volatile field" doesn't seem sufficient to me.

From my understanding of the C# standard, volatile means:

[1] volatile reads have acquire semantics, i.e. no memory operation can be moved before;

[2] volatile write have release semantics, i.e. no memory operation can be moved after.

Add to that the rule that [3] no optimization should change the behavior of a single threaded program.

Now consider Stephen's code above:

var cur = m_paused;

return cur != null ? cur.Task : s_completedTask;

Can you explain which rule above has been broken if "cur" in the expression "cur.Task" is read from m_paused again rather than from

a temporary?

Clearly rule [1] has not been violated because no memory operation has been moved before the statement "var cur = m_paused".

Rule [3] is fine as well: as long as there's no other thread m_paused can't have changed.

Rule [2] doesn't matter as there is no volatile write.

Maybe the missing part of the standard is simply: no read/write can be introduced/eliminated on a volatile variable?

Bonus chatter: how does all this relate to non-volatile variable? What if I rely on a few MemoryBarrier or Interlocked operations

rather than an always volatile field?

I think the confusion arose from the vague wording of the second article that basically states "read introductions -- or

eliminations -- can happen in some circumstances" without providing the precise rules that dictate when such

introduction/elimination is actually allowed or when it is forbidden.

I couldn't find a precise definition anywhere, information on the web only seems to focus on the ordering issues and

acquire/release semantics.

Or maybe it's just me who doesn't understand how acquire semantic and a read introduction are related?

re: Cooperatively pausing async methods

Igor Ostrovsky - MSFT — Wed, 15 May 2013 19:33:38 GMT

jods: See section "Publication via Volatile Field" of the Part 1 of my article (msdn.microsoft.com/.../jj863136.aspx). No read may be introduced that would break the acquire-release semantics of a volatile field.

re: Cooperatively pausing async methods

jods — Wed, 15 May 2013 18:22:55 GMT

Like Gebb I would like to understand how to prevent read introductions but I'm not satisfied yet. I searched the web but couldn't find a definitive, precise answer.

This is unfortunate because it's critical to write correct concurrent code. For instance your method WaitWhilePausedAsync would not be correct if a read introduction was possible.

Maybe you could write a blog post on the topic?

You clear the issue in the following comment above:

"read introduction is one mechanism by which a memory reordering might be introduced"

With the implicit argument that because a volatile variable prevents reordering, the read introduction is prevented.

But!

The part 1 of this article, which you've linked to, explicitely disagrees with you. It explicitely describes "read introduction" as a "NON-reordering optimization". I quote the relevant paragraph:

"*Non-Reordering Optimizations* Some compiler optimizations may introduce or eliminate certain memory operations. For example, the compiler might replace repeated reads of a field with a single read. Similarly, if code reads a field and stores the value in a local variable and then repeatedly reads the variable, the compiler could choose to repeatedly read the field instead."

If a "read introduction" is not a reordering optimization -- which makes sense -- I see nothing in the definition of a volatile variable that prevents it. Quoting the volatile explanation from the same article:

"*Volatile Fields* The C# programming language provides volatile fields that constrain how memory operations can be reordered. The ECMA specification states that volatile fields provide acquire-release semantics (bit.ly/NArSlt).

A read of a volatile field has acquire semantics, which means it can’t be reordered with subsequent operations. The volatile read forms a one-way fence: preceding operations can pass it, but subsequent operations can’t. [...]"

Can you please shed some light on this issue? What are the precise rules regarding read introduction, when is code safe, when is it not?

Thanks!

re: Cooperatively pausing async methods

Gebb — Mon, 11 Feb 2013 16:01:08 GMT

Thank you, Stephen! The article doesn't state explicitly that volatileness prevents read introduction, but I take it from your replies that it does. Good news.

re: Cooperatively pausing async methods

Stephen Toub - MSFT — Mon, 11 Feb 2013 15:45:18 GMT

@Gebb: Yes, "read introduction" is one mechanism by which a memory reordering might be introduced.

re: Cooperatively pausing async methods

Gebb — Mon, 11 Feb 2013 08:28:51 GMT

@Stephen: As I understand volatile fields prevent certain kinds of memory operations reordering. But does this concept of "read introduction" have anything to do with reordering?