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.
View attachment 349144
https://nordvpn.com/cybersecurity/glossary/software-interrupt/

So I must already be an asynchronous programmer, and never realised. (Or does it mean a programmer who is never on time?)

 

The C# await keyword is basically very powerful eye candy.

It effectively creates logic like this (greatly simplified)

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);
}

From code like this:

void async SomeFunction() // A user button press event might call this
{
   // Lets start the file download
   await BeginFileDownloadAsync (url);
   { // braces here just to emphasize that an invisible function exists, we don't need to code them.
     // Save the file to diask
     SaveFile(info);
   }
}

So a call to SomeFunction returns almost immediately and then resumes (perhaps many seconds later) at the statement following the await (once the IO completes). The callback function wraps all the code following the await operation. It wraps that code in an invisible function so that it runs as shown in the first example but looks like the second example.

This was one of the reasons Microsoft introduced nested functions to C#, it made await syntax possible. There's more involved though, cancellations, cross thread exception propagation and closures are all handled neatly by this model.

 

So I must already be an asynchronous programmer, and never realised. (Or does it mean a programmer who is never on time?)

Every embedded systems programmer uses the same basic asynchronous semantics as await or similar language keywords when they write an ISR callback function. Await just hides the low-level details.

That's a good thing for the applications level programmer, as most as clueless about low-level hardware details as most embedded guys are clueless about web-app coding frameworks.

 

If we could pass a label for a callback rather than a function, we could kind of make C look a little bit like that await syntax:

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

done:

   // Save the file to disk
   SaveFile(info);
}

 

If we could pass a label for a callback rather than a function, we could kind of make C look a little bit like that await syntax:

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

done:

   // Save the file to disk
   SaveFile(info);
}

If you want C abominations, then use this:

https://www.tutorialspoint.com/c_standard_library/c_function_longjmp.htm

 

If you want C abominations, then use this:

https://www.tutorialspoint.com/c_standard_library/c_function_longjmp.htm

Actually yes, that's an idea, I used that many many years ago and forgot it existed!

 

Here after only Async. Forever!

Don't get too narrow. It's another tool to optimise resources for the problem at hand - a variety of tools to call on is the mark of experience.

The class of problems that can be improved are a small subset of programming.

True, but the chosen solutions to problems are usually open to improvement. I've spent good proportion of my career rethinking and improving others' code by large margins - a sad reflection on the average analyst/programmer.

 

Don't get too narrow. It's another tool to optimise resources for the problem at hand - a variety of tools to call on is the mark of experience.



True, but the chosen solutions to problems are usually open to improvement. I've spent good proportion of my career rethinking and improving others' code by large margins - a sad reflection on the average analyst/programmer.

Not everyone can be from:


I tend to think the over optimization (as an excuse to make things cheaper instead of better) in hardware and software makes systems fragile. They tend to break catastrophically instead of bending.

 

Isn't "over optimization" an oxymoron? Optimized past the optimum? A common failing in software, I grant you, and fragility is as large a part of poor design as poor performance or maintainability.