Asynchronous programming and cooperative multitasking • Hacker News Board

Re: Asynchronous programming and cooperative multitasking

#21

Post by greglindahl » Sun, Feb 10, 2019, 5:14 PM UTC

0x445442 wrote: post #17

spinningslate wrote: post #8

Good job at highlighting async as being cooperative multi-tasking. Those of us old enough will remember the fanfare when both Mac and Windows moved from cooperative to pre-emptive multi-tasking models. To adapt a well known phrase, every non-trivial cooperative application includes a half-baked, buggy implementation of a pre-emptive scheduler. We know that pre-emptive scheduling of isolated processes is a good abstra…

I'm currently working on a project that's implementing this whole pattern using AWS. 1.) Requests are written to a DynamoDB table 2.) a Lambda subscribes to the Dynamo event stream 3.) each event from the stream causes the Lambda to make an async call to an external system 4.) A message (with a delay) is sent to SQS from the Lambda that the async call has been made 5.) Another Lambda reads from the SQS queue and upda…

It's similar to how you use Linda (1986), which wasn't novel when it was invented, either.

Re: Asynchronous programming and cooperative multitasking

#22

Post by Matthias247 » Sun, Feb 10, 2019, 6:33 PM UTC

0x445442 wrote: post #17

spinningslate wrote: post #8

Good job at highlighting async as being cooperative multi-tasking. Those of us old enough will remember the fanfare when both Mac and Windows moved from cooperative to pre-emptive multi-tasking models. To adapt a well known phrase, every non-trivial cooperative application includes a half-baked, buggy implementation of a pre-emptive scheduler. We know that pre-emptive scheduling of isolated processes is a good abstra…

I'm currently working on a project that's implementing this whole pattern using AWS. 1.) Requests are written to a DynamoDB table 2.) a Lambda subscribes to the Dynamo event stream 3.) each event from the stream causes the Lambda to make an async call to an external system 4.) A message (with a delay) is sent to SQS from the Lambda that the async call has been made 5.) Another Lambda reads from the SQS queue and upda…

The challenge with that kind of system is flow control. Essentially everything is coupled by queues without a feedback loop. And once the system gets under load, those queues might run fuller and fuller until the whole system fails.

It’s actually similar than an in-program model where you just asynchronously queue void functions in threadpools without knowing how many actually run.

The fact that you are only running on top of managed services and that AWS can scale really well might mitigate the problem. And if you have to process all events and can not fail early or move backpressure on the initial caller there might not really be a better solution anyway. But you should be aware about it.

Re: Asynchronous programming and cooperative multitasking

#23

Post by greglindahl » Sun, Feb 10, 2019, 6:45 PM UTC

sametmax wrote: post #11

spinningslate wrote: post #8

Good job at highlighting async as being cooperative multi-tasking. Those of us old enough will remember the fanfare when both Mac and Windows moved from cooperative to pre-emptive multi-tasking models. To adapt a well known phrase, every non-trivial cooperative application includes a half-baked, buggy implementation of a pre-emptive scheduler. We know that pre-emptive scheduling of isolated processes is a good abstra…

Cooperative multi-tasking if terrible is you don't have control over what the others are doing, but in your program you generally do. It also have the benefit of making concurrent access much easier to reason about without having to resort to message passing or immutability, yet locks are rarely necessary. As usual, it's a trade off.

I've learned (the hard way) that any in any project with more than one programmer, sometimes you don't have control over what the others are doing.

And on a bad day, I can do "the bad thing" to myself.

One way to help mitigate this is good tooling. A warning that a piece of async computation took longer than expected can be very useful if you expect everything to finish in a few tens of milliseconds.

Re: Asynchronous programming and cooperative multitasking

#24

Post by jondubois » Sun, Feb 10, 2019, 8:23 PM UTC

With JavaScript, you can also use `for-await-of` loops to process asynchronous data as an alternative to using callbacks or green threads.

I've been doing a lot of open source work on this in the past few months: https://hackernoon.com/getting-started-with-asyngular-bbe3dd...

Re: Asynchronous programming and cooperative multitasking

#25

Post by lotia » Mon, Feb 11, 2019, 7:19 AM UTC

maayank wrote: post #13

spinningslate wrote: post #8

Good job at highlighting async as being cooperative multi-tasking. Those of us old enough will remember the fanfare when both Mac and Windows moved from cooperative to pre-emptive multi-tasking models. To adapt a well known phrase, every non-trivial cooperative application includes a half-baked, buggy implementation of a pre-emptive scheduler. We know that pre-emptive scheduling of isolated processes is a good abstra…

Can't agree more. As someone who've done lots of work on both preemptive- and cooperative- multitasking codebases I'm perplexed by how many frameworks dive head-first into the latter.

Interesting observation. Any theories on why? As someone who has consumed but not written much by way of schedulers I’d be keen to hear thoughts.

Re: Asynchronous programming and cooperative multitasking

#26

Post by maayank » Mon, Feb 11, 2019, 1:10 PM UTC

lotia wrote: post #25

maayank wrote: post #13

Earlier quoted context omitted.

Can't agree more. As someone who've done lots of work on both preemptive- and cooperative- multitasking codebases I'm perplexed by how many frameworks dive head-first into the latter.

Interesting observation. Any theories on why? As someone who has consumed but not written much by way of schedulers I’d be keen to hear thoughts.

(I assume you're asking why frameworks delve headfirst into coop, please correct me if I'm wrong)

Cooperative multitasking has much of the semantics (and thus semblance) of preemptive multitasking while also having the allure of not needing the harder (either with respect to understanding or actual usage) semantics of locking, the mental accounting related to thread safe algorithms, etc.

In other words, you get the semantics of concurrency (e.g. tasks and working queues) without the overhead of synchronizing. That sounds very alluring, but in practice I would like to not delve into specialized semantics AT ALL unless I'm expecting some speed/scalability gains, where the bulk of it comes from actual parallel execution, either in the form of different cores or different nodes. And then you need in any case to use the same semantics concurrent (i.e. cooperative) frameworks try to avoid, e.g. in the form of synchronizing between processes but with much less tooling because this is a second-tier scenario in most cooperative multitasking frameworks I've seen.

In other words, you don't get the speedups that are worth the mental effort of using the semantics in the first place. The only exception I've seen is a code base properly utilizing their I/O "breaks" for cooperation and indeed I see cooperative multitasking frameworks often touting I/O intensive applications as an ideal candidate. But, please note that:

1. Programmers usually overestimate how much I/O (or any resource usage) blocks. The codebase I was referring to was an actual filesystem.

2. Behind toy programs you still need to do a lot of thread-safe type accounting. You're not susceptible to cache-coherency issues, but that's about it.

Phew, didn't think I have so much to say about it.