Timilearning

MIT 6.824: Lecture 2 - RPC and Threads

This course is based on the Go programming language, and this post will introduce some features in Go that make it well suited for building concurrent and distributed applications.

Table of Contents

Threads

Threads are the unit of execution on a processor. When a program is run on your computer, that starts up a process. That process can then be made up of one or more threads which execute different tasks. Some key things to note about threads are:

Why use threads?

Go has Goroutines, which are lightweight threads for managing concurrency.

What if we couldn't have multiple threads?

There's a concept of Event Driven Programming where a process only has a single thread which listens for events and executes user specified functions when the event occurs. This concept is used by Node.js and the thread is known as the event loop.

The key thing here is that although the application appears to run on a single thread from the programmer's perspective, the runtime internally uses multiple threads to handle tasks. The main difference is that the programmer does not have to deal with these internal threads and the challenges of coordination between them. All the programmer has to do is specify callback functions to be executed on the main thread when those background tasks have completed.

When the single thread receives an event (like a button click or a task completion), it pauses its current task, executes the callback function for the event, and then returns to the paused job.

Downsides of Event-Driven Programming

Threading Challenges

Remote Procedure Call (RPC)

RPC is a means of client/server communication between processes on the same machine or different machines. Here, the client executes a procedure (function/method) on a remote service as if it were a local procedure call.

The steps that take place during an RPC are as follows [1]:

The main benefit of this is that it simplifies the process of writing distributed applications since RPC hides all the network code into stub functions. Programmers don't have to worry about details like data conversion and parsing, and opening and closing a connection.

Note: The client knows what server to talk to through binding. Go has an RPC library to ease this communication between processes. In Go's RPC library, the server name and port are passed as arguments to a method when setting up the connection.

Dealing with failures

From the perspective of a client, failure means sending a request to the server and not getting a response back within a particular time out. This can be caused by a number of things including lost packets, slow server, crashed server, and a broken network.

Dealing with this is tricky because the client would not know the actual status of its request. Possible scenarios are:

The simplest way to deal with a failure would be to just retransmit the request; however, if the server had already executed the request, resending it could mean the server executes the same request twice, which could lead to unwanted side effects. This failure handling method works well for idempotent requests i.e. operations that have the same effect when executed multiple times as if they were executed once. Many operations are not idempotent, and so we need a more general approach to handle failures.

RPC Semantics

An RPC implementation can use any of the following semantics for making requests :

Go RPC

Go RPC guarantees at-most-once semantic. If it doesn't get a reply, it will just return an error. The client can opt to retry a failed request, but it is up to the server to handle duplicate requests to maintain the at-most-once guarantee; what if the request actually executed but the reply got lost?

Some complexities related to at-most-once communication between processes are:

[1] Remote Procedure Call (RPC) - Lecture notes from Worchester Polytechnic Institute

Further Reading

Last updated on 15-05-20.

mit-6.824 distributed-systems learning-diary

To get notified when I write something new, you can subscribe to the RSS feed.

A small favour

Did you find anything I wrote confusing, outdated, or incorrect? Or do you have an answer to a question I posed here? Please let me know! Just write a few words below and I'll be sure to amend this post with your suggestions.

← Home