1

Synchronous and Asynchronous Programming Paradigms

An algorithm is defined broadly in the Merrian-Webster Dictionary as a 'step-by-step procedure for solving a problem or accomplishing some end'. Step-by-step is commonly understood to imply that the steps are executed sequentially, that is to say, step 0 at time instant 0 and step 1 at time instant 1, etc.

Asynchronous programming is very difficult to grasp because it introduces the idea that there could be more than one line of execution running at the same time, which means you might have situations in which step n and step n+1 of your algorithm are executed at the very same instant t. The following image presents an approximation of both synchronous and asynchronous models. Note the performance gain obtained by implementing an asynchronous solution:

Figure 1.1: An oversimplified timeline comparison between synchronous and asynchronous solutions

The consequences of this are huge: with the right design, algorithms can be executed in dramatically less time, freeing up resources and mental energy for programmers and companies alike.

Asynchronous programming poses a number of challenges that must be understood if we are to unlock the full potential of these new algorithms. (How do you split the tasks you want to execute in parallel? What happens if one task ends before another? Who coordinates the tasks? Etc.) That's why we start this book with a discussion of the core concepts that a developer must understand to get started:

• Synchronous and asynchronous programming
• Operating system process and threads
• Green threads, coroutines and fibers
• Callbacks, promises and futures
• Challenges of asynchronous programming

Free Benefits with Your Book

Your purchase includes a free PDF copy of this book along with other exclusive benefits. Check the Free Benefits with Your Book section in the Preface to unlock them instantly and maximize your learning experience.

Technical requirements

Sample code provided in this chapter is available on Github (https://github.com/PacktPublishing/Asynchronous-Programming-in-Python/tree/main/Chapter01). You don't need anything special installed on your computer besides Python 3; if you need help with installation check the community instructions at https://wiki.python.org/moin/BeginnersGuide.

Understanding synchronous and asynchronous programming

As in many aspects of life, programming requires clear objectives if success is to be achieved, and those objectives are usually formulated as objectively testable requirements. A set of requirements represents all the characteristics that a software solution must exhibit to be deemed satisfactory, i.e. the things that you must check to accept or reject a solution. They can include functional and non-functional aspects. Functional aspects are directly related to the product definition ('If I do X, Y happens') whereas non-functional requirements are not directly related to the solution per se but may be required for other reasons (e.g. 'Implement using the Cloud to guarantee a certain level of availability').

For example, in sports or board games there is usually the clear objective of winning a match, and it is usually easy to evaluate whether the player has achieved that objective or not. In basketball, you can see if the ball has passed through the hoop. The shot clock is an example of a non-functional requirement: it's not necessary for scoring but is an important rule of the game nonetheless that must be complied with to avoid a penalty.

Synchronous programming: chess

A good way to learn how to think in a synchronous and structured way is to solve little chess puzzles. Chess is a 'complete information' game, which means that everybody involved in a game has complete awareness of the situation of the game. A chess puzzle is an individual practice mode in which the player must find a solution for an established game situation to finish the game (checkmate). Usually, chess puzzles have an optimal solution which is defined as the solution requiring the fewest moves to reach checkmate.

Important note

If you don't know the rules of chess, a good introduction is available from the libre/free community-driven server located at https://lichess.org/learn.

The following chess puzzle can be optimally solved by the white player in three moves:

Figure 1.2: A chess puzzle solvable in three moves by white

To solve this kind of problem the player must make their moves sequentially, taking into account the global state of the game (the positions of the pieces on the board), the value of each piece (for in chess each available piece type has a different value), and the potential reactions the opponent may make to the player's moves. Remember that chess is a turn-based strategy game.

Many problems can be solved in this way, which we refer to as synchronous programming - the decomposition of steps into a cascade having a single line or thread of control. The execution of each step and time of execution are perfectly synchronized, and each step has full information about the global status, variables and available resources.

The following table shows the solution of the previous puzzle in three moves for white. Notice that the flow might change if conditions varied with the opponent's moves (for example if in Step 1(b) the black player made a mistake):

Step

White (a)

Black (b)

1

Bh8

Nd4

2

Qd4

Be6

3

Qg7

Table 1.1: Solution for the chess puzzle

Asynchronous programming: soccer

A game like soccer is much more complex than chess. It involves two teams composed of 11 players each, and players are assigned positions (goalkeeper, defender, midfielder, forward) which impact their initial locations and potentially their ability to perform certain actions. The overall objective is to score (cause the ball to cross the opponent's goal line). Any player can do this, and although at any given moment one team is defending and the other is attacking, the roles are fluid and continuous and 'turns' at shooting to goal are often unexpected.

The nature of the game allows for an infinite number of strategies. Usually, a team's strategy involves not only retaining the ball but also making teammates run to distract the opposing team and to gradually occupy favorable 'real estate' on the field to improve the chances of any given shot.

The following three diagrams show a typical soccer play in which a defender takes control of the ball and after three moves scores a goal:

Figure 1.3: A soccer play starts with number 2 making a pass to number 10

The main execution timeline is always the one in which the ball is involved. Here it starts with player 2 taking control of the ball and making a pass to player 10, but once the pass is executed player 2 starts to run to a new position.

Figure 1.4: Second move: a dribble by number 10 and a run by number 2

At the second instant in time, multiple things are happening: player 10 dribbles past an opponent, while players 9, 2, and 11 move downfield for better positioning.

Figure 1.5: Third move: number 2 scores

At the third instant, player 10 waits until player 2 is in position to score, after which he passes the ball and player 2 is able to hit the net. The main execution line (scoring the goal) cannot be achieved if the supporting, parallel executions by multiple players are not completed.

Note

The previous example is an adaptation of a real play executed by the Slovenian national soccer team in the 2024 UEFA European Football Championship, the match report for which is available at https://www.uefa.com.

In the same way, asynchronous programming is a technique in which some of an algorithm's steps are executed in different lines of control than the main one, and those executions may occur simultaneously. Simultaneous execution is usually managed by the operating system or the programming language runtime, but simultaneous execution is not a requirement for asynchronous programming: asynchronous operations can also be run sequentially if desired.

It's important...