3

After reading a lot on await, I just can't keep comparing it the the DoEvents combined with a loop in the former VB6 language. Am I thinking this right?

This is only to make myself an idea on how it works and I felt that this could be a nice and simple explanation (of course technically not exact).

Thanks for your inputs!

codea
  • 1,439
  • 1
  • 17
  • 31
  • No. IMHO, they are entirely different. DoEvents still exists in .NET as Application.DoEvents() – Thangadurai Jan 05 '15 at 11:24
  • Maybe the misunderstanding is that you think: How can the UI be unblocked although the code is paused during a wait? Is that your thinking? – usr Jan 05 '15 at 11:36
  • 1
    My thinking is more about the similarity of the principle of operation, not really about internals... I think Stephen Cleary got it for the first part of his explanation, I could not explain better. – codea Jan 05 '15 at 12:20

3 Answers3

3

In some ways they can appear similar at first glance. DoEvents will run a nested message loop to allow other methods to run on that thread before the current method finishes. Similarly, await will "yield" control to other methods, allowing other code to run on that thread before the current method finishes.

However, there is one very, very important difference. DoEvents keeps the current call stack; when it invokes other methods, it does so directly; this causes serious problems with unexpected reentrancy, and is the primary reason for the oft-repeated phrase "DoEvents is evil". In contrast, await returns all the way up, so there's no direct reentrancy.

Also, DoEvents is only similar to await when used on a UI thread. await can be used in many other contexts, too.

Stephen Cleary
  • 437,863
  • 77
  • 675
  • 810
  • Nice explanation, I like it and I am glad that I was not too much off the track. This is very useful, thanks! – codea Jan 05 '15 at 12:23
2

No, they're not the same. DoEvents had nothing to do with multithreading, it just processed window messages that were sat in your message queue in order to make it look like your gui was being responsive. That processing always took place on the thread that called DoEvents.

Sean
  • 60,939
  • 11
  • 97
  • 136
  • But doesn't `await` in fact also sometimes run the processing on the same thread that executed `await`? Depending on the synchronization context. http://stackoverflow.com/questions/13993750/the-async-and-await-keywords-dont-cause-additional-threads-to-be-created – MarkJ Jan 05 '15 at 13:18
1

Maybe. Doevents allows VB6 co-opertative multithreading, seperate to the CPU's multithreading (like Win 16 multitasking). You have all the synchronisation problems of CPU multiple threading,but they can be solved with normal programming as you control switching (so no command will be preempted halfway through), unlike CPU synchronistion where special CPU instructions must be used. The CPU, because you are not using it's multithreading, treats you as a single thread (as you are to the CPU).

DoEvents is a Win16 compatability thing. It should not be used, it's dangerous, and people use it to solve imaginary problems. IT CAUSES BUGS.

What it does. It interupts your function, and jumps to the VB6 runtime to clear the message queue, making your procedure reentrant and changing the valuses your function was using to something else. It then calls WinAPI sleep(0) for Windows to give messages to all programs. ANYTHING can happen after that.

The only thing it's useful for is making a form update before a function finishes.

But it's so dangerous.

Serenity
  • 11
  • 1