Async programming models part I
Asynchronous programming is everywhere around us and it’s here to stay. You might have noticed that CPU’s keep getting more cores as time goes by. Therefore, it would be a shame to let all those cores go unused in your app. In this article I shall be your guide through the various async programming patterns that I have used.
Plain old threads
These are the most powerful tools at your disposal. A kind of all-purpose swiss army knife that you can do everything with. The basic pattern is that you have a function that is going to run on a separate thread. You pass in any data that the thread needs and you are good to go. Every pattern we will cover here can be reduced to this model (because this is what computers understand).
What are they good for
Plain threads are good for long, custom tasks that you need to run in the background. Do you want to build a server that handles multiple requests at the same time, then this is the way to go.
The problem with plain old threads
Albeit they are very powerful tools, threads can be a bit hard to use. You need to make sure you are passing the right data. Then you need to make sure you are getting the right data from the thread. And you need to all of this while make sure you are not causing any synchronization issues. That is not as easy as it seems. All the patterns share the synchronization issues.
Additionally, you need to decide on the number of threads to use and this is not a trivial task.
Where can I find this
All programming languages worth a damn provide some sort of API you can use for this
Queue of events
In this async programming model you begin with a bunch of threads that idly wait for something to happen. You also have a queue of events that keep track of what happens. When something happens, one of the threads picks up the work(usually the first idle thread). Then it does the work. Then it goes back to twiddling its thumbs until something new happens.
What are they good for
You should use this pattern when you need to respond to something happening in the world. These events can be HTTP requests if you’re building a server, user actions or other threads work.
Threads can be added or removed from the pool as needs demand. Most of the times this can be done automatically, so this is one less thing you need to worry about.
In simpler terms: If your app can be described as When this happens, then this should happen!, you can use this pattern.
Problems with a queue of events
You have significantly less control on the threads than you would normally do. Additionally, you need to add all the info required by the thread in the event data. From time to time, this can be tricky.
The queue itself can be a problem. Events can keep piling up during busy times or if there is a deadlock with the threads. If the queue grows too big events can either be dropped (causing loss of data) or they can block the system (causing much worse damage)
Where can I find this
This is all for today. Map-reduce and promises coming soon. Are there any async patterns you want me to cover?
Part II here.