Here after only Async. Forever!

Hi Members,
I myself am feeling like that I am overusing this forum. I don't have much friends in real to ask these kinds of questions. Hope you understand. Please don't take it otherwise.
With Hope,

Prabhakaran

 

Glad to see that you are such an active participant.

Can you spell out your question clearly?

 

I have come to know a few years back that there is another method of programming exists. It's called Asynchronous Programming. As I know only VBA code then, I was really attracted on knowing ways to achieve a result very quick using that way of programming. What I assume, so far is that Asynchronous mode utilizes all the threads and cores of a single system instead of relying on continuous code flow. For the past 3 days, My system is running a code to refine a word file using the VBA code I have written. I know that VBA doesn't support Async tasks but VB.Net and VSTO does.

 

I have come to know a few years back that there is another method of programming exists. It's called Asynchronous Programming. As I know only VBA code then, I was really attracted on knowing ways to achieve a result very quick using that way of programming. What I assume, so far is that Asynchronous mode utilizes all the threads and cores of a single system instead of relying on continuous code flow. For the past 3 days, My system is running a code to refine a word file using the VBA code I have written. I know that VBA doesn't support Async tasks but VB.Net and VSTO does.

What's your question?

Old stuff that once created a class of computers called Dataflow machines that used various versions of Functional languages.
https://en.wikipedia.org/wiki/Dataflow_architecture

People stopped using specialized hardware when general purpose CPUs became so much faster, powerful and could analyze programs to be automatically (or be easily written using common languages embedded programmers use, like 'C') be parallelized using standard programming frameworks. Interrupts, DMA and various hardware today makes effective Asynchronous Programming easy (I use it all the time of 8-bit controllers) if you know the design pattern. It just requires a little motivation to learn.

Functional languages have their place (math intensive functions with no run state) but it's not in the embedded programming space usually.

One of my old CS school books.

 

What's your question?

Old stuff that once created a class of computers called Dataflow machines that used various versions of Functional languages.
https://en.wikipedia.org/wiki/Dataflow_architecture

People stopped using specialized hardware when general purpose CPUs became so much faster, powerful and could analyze programs to be automatically (or be easily written using common languages embedded programmers use, like 'C') be parallelized using standard programming frameworks. Interrupts, DMA and various hardware today makes effective Asynchronous Programming easy (I use it all the time of 8-bit controllers) if you know the design pattern. It just requires a little motivation to learn.

Functional languages have their place (math intensive functions with no run state) but it's not in the embedded programming space usually.
View attachment 349120
One of my old CS school books.

View attachment 349121
View attachment 349122
View attachment 349123

Thanks for your detailed reference.
I am running a VBA task for more than 3 days Now (Word VBA Program) . It has achieved only 60% so far. Goanna try changing it to async once it finishes. will be my first every async code. Thanks Again.

 

Thanks for your detailed reference.
I am running a VBA task for more than 3 days Now (Word VBA Program) . It has achieved only 60% so far. Goanna try changing it to async once it finishes. will be my first every async code. Thanks Again.

Don't expect too much. The class of problems that can be improved are a small sunset of programming.

 

I have come to know a few years back that there is another method of programming exists. It's called Asynchronous Programming. As I know only VBA code then, I was really attracted on knowing ways to achieve a result very quick using that way of programming. What I assume, so far is that Asynchronous mode utilizes all the threads and cores of a single system instead of relying on continuous code flow. For the past 3 days, My system is running a code to refine a word file using the VBA code I have written. I know that VBA doesn't support Async tasks but VB.Net and VSTO does.

Get this (short but excellent) book:



Ignore the emphasis on C# 5, that's the version of the language that added the new await and async keywords, but the book applies to all versions since C# 5.

 

Get this (short but excellent) book:

View attachment 349129

Ignore the emphasis on C# 5, that's the version of the language that added the new await and async keywords, but the book applies to all versions since C# 5.

Thank you so much. I am gonna read it despite of being a VB.Net Developer. Just asking, is there another version of same book on VB?

 

Thanks for your detailed reference.
I am running a VBA task for more than 3 days Now (Word VBA Program) . It has achieved only 60% so far. Goanna try changing it to async once it finishes. will be my first every async code. Thanks Again.

Understand the intent of async/await keywords in C# and VB .Net.

It is primarily there to avoid having OS threads waiting, blocking, sleeping. That's it, that's the primary goal.

Async has been around in Windows since the first version of Windows NT, but there were no special language keywords (and C# didn't even exist back then).

Don't confuse async with parallel processing, they are different concepts.

The new keywords in C# make async code easier to write and easier to understand, that's all they do, the actual asynchronous behavior inside the system is the same as it's always been.

So actual async on Windows (which is ultimately exposed via the C Win32 API) uses this model:

1. Start a slow operation (like getting data from the web).
2. When starting the operation pass in a function, this function will be called (by the operating system) when the operation finishes which might be in ten seconds time.
3. In that function, deal with the data that came in and tell the operating system that you've finished the operation.

That's it, that's basically async on Windows and other operating systems.

Here's pseudo code in C:

void SomeFunction() // A user button press event might call this
{
   // Lets start the file download
   BeginFileDownloadAsync (url, EndFileDownload);
}

void EndFileDownload(Info)
{
   // Save the file to diask

   SaveFile(info);
}

The key points are that when SomeFunction is called it returns very quickly, starting the operation is very fast.

And some time later, the function EndFileDownload will be automatically called by the OS.

These two functions are written by the developer, they are part of the application.

So think about this and read up, if you don't get a solid grasp of this you likely won't really understand the async/await keywords.

 

Understand the intent of async/await keywords in C# and VB .Net.

It is primarily there to avoid having OS threads waiting, blocking, sleeping. That's it, that's the primary goal.

Async has been around in Windows since the first version of Windows NT, but there were no special language keywords (and C# didn't even exist back then).

The new keywords in C# make async code easier to write and easier to understand, that's all they do, the actual asynchronous behavior inside the system is the same as it's always been.

So actual async on Windows (which is ultimately exposed via the C Win32 API) uses this model:

1. Start a slow operation (like getting data from the web).
2. When starting the operation pass in a function, this function will be called (by the operating system) when the operation finishes which might be in ten seconds time.
3. In that function, deal with the data that came in and tell the operating system that you've finished the operation.

That's it, that's basically async on Windows and other operating systems.

Here's pseudo code in C:

void SomeFunction() // A user button press event might call this
{
   // Lets start the file download
   BeginFileDownloadAsync (url, EndFileDownload);
}

void EndFileDownload(Info)
{
   // Save the file to diask

   SaveFile(info);
}

The key points are that when SomeFunction is called it returns very quickly, starting the operation is vert fast.

And some time later, the function EndFileDownload will be automatically called by the OS.

So think about this and read up, if you don't get a solid grasp of this you likely won't really understand the async/await keywords.

Already so many fresh ideas are running inside my Mind. Will be very interesting i expect... Thanks.

 

Thank you so much. I am gonna read it despite of being a VB.Net Developer. Just asking, is there another version of same book on VB?

https://learn.microsoft.com/en-us/dotnet/visual-basic/programming-guide/concepts/async/

You may want to consider learning more about C# if you're eager to learn async, while VB can do some of the things C# can, it's a dead language now, no new project or system should really use VB without a very very strong justification IMHO.

 

https://learn.microsoft.com/en-us/dotnet/visual-basic/programming-guide/concepts/async/

You may want to consider learning more about C# if you're eager to learn async, while VB can do some of the things C# can, it's a dead language now, no new project or system should really use VB without a very very strong justification IMHO.

Started reading the article. Thanks.

 

Already so many fresh ideas are running inside my Mind. Will be very interesting i expect... Thanks.

Think about how people work. We might have a phone team that get calls about placing orders for products. Those people just take the call and start the order processing, they have nothing to do other than that job. Once they've taken a call and started order processing, they are free to take another call.

Then we have dispatchers, they get sent a message every time there's a new order ready to ship, they get the completed order, stick it in a cardboard box and mail it out.

Async simply mirrors the real world, where workers focus on what they can do quickly, and nothing more, the two teams work independently and at different rates, unaware of each other actually.

Think of a thread in Windows as one of these people.

 

Think about how people work. We might have a phone team that get calls about placing orders for products. Those people just take the call and start the order processing, they have nothing to do other than that job.

Then we have dispatchers, they get sent a message every time there's a new order ready to ship, they get the completed order, stick it in a cardboard box and mail it out.

Async simply mirrors the real world, where workers focus on what they can do quickly, and nothing more.

Nice metaphor...

 

Nice metaphor...

Its pretty close to reality too, we don't lose much when we use this metaphor and it makes it easier to explain this kind of code to non-techies, business staff etc.

 

"Don't confuse async with parallel processing, they are different concepts"

All the same principle of utilizing resources. Async is just a software OS layer abstraction of a form of parallel processing. There is a lot of overlap in the design of both types of systems depending on what the I/O is.
You can fake it at the software level is a simple 8-bit controller using ASM.

https://medium.com/@cummingsi1993/the-difference-between-asynchronous-and-parallel-6400729fa897

Why does it matter?

The differentiation is important. If speaking about a particular feature a developer tells me that its executing ‘in parallel’ my first thought is of something like this third example. If we were speaking about a bug my mind is going to go towards race conditions, or other problems that might come up with parallel designs. On the other hand saying that its asynchronous just tells me that its not blocking the UI thread.

For example, suppose we are discussing a feature that uploads files. If you say its parallel i assume i can upload multiple files simultaneously. If you say its asynchronous i assume that i can upload one file and the UI thread is not blocked while it is uploading. The difference is subtle but significant.

 

"Don't confuse async with parallel processing, they are different concepts"

All the same principle of utilizing resources. Async is just a software OS layer abstraction of a form of parallel processing.

https://medium.com/@cummingsi1993/the-difference-between-asynchronous-and-parallel-6400729fa897

Perhaps but async (as used on Window anyway) works fine on even a single core CPU, it's still a legitimate abstraction and parallel isn't possible with a single core CPU.

There's certainly an overlap of concepts though.

 

Perhaps but async (as used on Window anyway) works fine on even a single core CPU, it's still a legitimate abstraction and parallel isn't possible with a single core CPU.

There's certainly an overlap of concepts though.

Windows is not entire world of programming platforms or platforms for computing.

Sure, true parallel processing isn't possible with a single core CPU but unless the running process is totally CPU bound (like cracking passwords) then there is the opportunity for faking parallel cores on a single CPU (like controllers that have independent specialized hardware modules to optimize common computing tasks like I/O or signal processing) to good advantage like using the hardware UART module instead of bit-banging serial I/O in software.

 

So is await the same as writing __asm__("WFI"); ?

 

So is await the same as writing __asm__("WFI"); ?

In the case of a OS user-land style await, it's the about the same as a software interrupt. Used for resource management.
It a scheduler feature for a process/ task/thread queue entry to enter a WAITING state until an assigned software interrupt (or some flag signal) tells the OS to change the process/task/thread queue entry for that to a READY/RUNNING state.

https://nordvpn.com/cybersecurity/glossary/software-interrupt/