- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
That's why I think adding async/await to C# was a very bad idea.
Because now it seems like asynchronus programming is sooo easy, just add a few keywords and they compiler will do the rest, almost no thinking required.
NOT.
You still have to think about data protection, locks, and so on.
I think as a result in a few years we will get even more applications with lot of strange race conditions and heisenbugs.
Admin
...timing issue? any. There’s a… I don't see... Second!
Admin
I promise I am frist. But due to a timing issue this post doesn't show up on top of the page.
Admin
As always, other languages have already had this problem figured out for a long time. Continuations.
Also Async/Promise/whatever looks an awful lot like it would admit a monad, don't you think?
Admin
By that logic we should all be writing in assembly, otherwise no one would ever truly appreciate everything that is happening and thus people would make more bugs, right? Of course not, not only would it take far longer to get anything done, but there would likely be more bugs for the same amount of functionality as the cognitive load of understanding vast amounts of assembly is far higher than understanding the equivalent 4 lines of code in something like C#.
Frameworks and libraries are not what makes bad programmers do bad things, it's the fact they are bad programmers. All the safety mechanisms in the world won't save them from themselves and the rest of the world, the only solution is to get rid of people who just don't fundamentally get software development.
Admin
comments rule
Admin
The combination of TypeScript with jQuery's (broken) promise implementation is a WTF in itself.
Admin
normally I would agree, but in the threading case I think forcing people to think a little bit more is a good idea...
Admin
Double clicking the word "heisenbug" was a bad idea.
Admin
I for one am dismayed by the current fad of async doodahs. They're pushed the most onto scriptkids who can't even think straight in a simple non-reentrant world. Worse, I see them used for light-load sequential workflows which should often be modal.
In my native tongue, these are best solved with the likes of Boost.Thread's interruptible_wait() and overlapped I/O. With the classes I made to support this, my code is far more readable than your typical async example.
Admin
Clicking that word was a FABULOUS idea!
Admin
you left out the wtf of trying to debug anything that uses knockout
Admin
The problem is not async/await, although I agree that it does make things seem simpler than they are. When it comes down to it async/await is merely sugar over Promise chaining. If you understand the latter then the former is simply a means of reducing the boilerplate involved.
The problem, as is clear, from the WTF post is that there are people out there who don't understand the concept of Promises at all and use them completely incorrectly. For such people no amount of sugar will help.
As for locks, etc, my general approach to async coding with Promises/Futures/Deferreds/Whatever the cool kids are calling it now is to try and adhere to some of the ideas behind FP as a means to achieve lockless concurrent code. It may not be applicable in every case but my experience has been that avoiding dangerous things (E.g. Mutating state shared between "steps" in a chain of async operations, etc) goes a long way towards obviating issues with async code.
Admin
Some people really ought to not think at all. Issues with race conditions and timing in multithreadded and async operations have been ubiquitous since the first utterance of the term "mutex" and "semaphore." Adding abstract logic around it doesn't change this fact at all. If you have a good understanding of async operations, you'll do fine with async/await, just as you would without them. If you have a bad understanding of async operations, you'll have a hard time with any operations regardless of the syntactic sugar.
Async utilities are just another tool for good programmers to be more concise in their programming. If a bad programmer abuses them, then they will have failed just as much without those tools.
Admin
The very first thing I looked at was -- what was returned at the end of the method. About 4 seconds later, yep, returning a resolved promise. This just screams "I don't know what async really is, and I don't know how to use it, just steal something from stackoverflow and write a little bit of business logic in between".
Whenever you encounter async code, look to see what is returned; and look to see where the returned promise is resolved/rejected. If there are race conditions, you'll find the bug.
Admin
You can never be too rich, too thin, or have too many unicorns
Admin
The timing with asynchronous problem is code
Admin
Making something too easy to do while making it difficult to get details on how it works can lead to situations like this. I have sometimes been caught like this and have to guess.
I remember, early in my career, I was looking at modifying an accounting system whose programs were written in Microsoft BASIC and called a machine language ISAM. We sent for the documentation and got effectively nothing. I gave it up. Some years later, I happened to work with the same accounting system. I was able to cobble something together for a report that had to read transactions from twelve monthly data files. It worked with some limitations, but because I was guessing, I could not guarantee that I was getting all of the transactions when the charts of accounts changed (thankfully rare) or that the program was anywhere near as efficient as it could have been. Unpleasant.
Admin
Promises, Promises! Now you have 2^n problems.
On the other hand, you might have a Broadway Show Hit.
Admin
Using Async/Await in C# still forces you to deal with the resulting information or non information. You don't end up with multiple code paths actually running in parallel unless you do so using other functions of the task/parallel library, most of which still make you deal with the results in a way that would prevent this problem. It presents other problems if you are calling to multiple functions in parallel that are all updating shared objects, but just using Async/Await by itself you can't really get yourself into that problem area. Besides, it is practically necessary to work in the modern sandboxes (UWP, etc) where you are forced to do all I/O calls in an async manner.
Admin
In sociology, a "promise" is a form of manipulation to get something, with no recourse if the promisser fails to perform as promised. Unfortunately this has leaked over into techie stuff.
Admin
Even intelligence succumbs under normal distribution, when given enough time. Especially when they work asynchronous on the same tasks.
ps Hope I didn't slaughter your beautiful language.
Admin
It gets better - after I submitted this, I found the following (shorted for brevity):
var promise = $.Deferred<boolean>();
$.ajax({ async: false, ... }).done(() => promise.resolve(true));
return promise;
Admin
Aren't we supposed to be using Fetch instead of AJAX if we're going to play nicely in Promise-land?