We already met a sequential execution while implementing the spider() function in the previous section. By applying the simple rules that we studied, we were able to organize a set of known tasks in a sequential execution flow. Taking that code as a guideline, we can then generalize the solution with the following pattern:

function task1(callback) { 
  asyncOperation(() => { 
    task2(callback); 
  }); 
} 
 
function task2(callback) { 
  asyncOperation(result () => { 
    task3(callback); 
  }); 
} 
 
function task3(callback) { 
  asyncOperation(() => { 
    callback(); //finally executes the callback 
  }); 
} 
 
task1(() => { 
  //executed when task1, task2 and task3 are completed 
  console.log('tasks 1, 2 and 3 executed');
}); 

The preceding pattern shows how each task invokes the next upon the completion of a generic asynchronous operation. The pattern puts the emphasis on the modularization of tasks, showing how closures are not always necessary to handle asynchronous code.

The pattern we described earlier works perfectly if we know in advance what and how many tasks are to be executed. This allows us to hardcode the invocation of the next task in the sequence; but what happens if we want to execute an asynchronous operation for each item in a collection? In cases such as this, we cannot hardcode the task sequence anymore; instead, we have to build it dynamically.

function spider(url, nesting, callback) { 
  const filename = utilities.urlToFilename(url); 
  fs.readFile(filename, 'utf8', (err, body) => { 
    if(err) { 
      if(err.code ! == 'ENOENT') { 
        return callback(err); 
      } 
 
      return download(url, filename, (err, body) => { 
        if(err) { 
          return callback(err); 
        } 
        spiderLinks(url, body, nesting, callback); 
      }); 
    } 
 
    spiderLinks(url, body, nesting, callback); 
  }); 
} 

function spiderLinks(currentUrl, body, nesting, callback) { 
  if(nesting === 0) { 
    return process.nextTick(callback); 
  } 
  const links = utilities.getPageLinks(currentUrl, body);  //[1] 
  function iterate(index) {                                //[2] 
    if(index === links.length) { 
      return callback(); 
    } 
 
    spider(links[index], nesting - 1, err => {             //[3] 
      if(err) { 
        return callback(err); 
      } 
      iterate(index + 1); 
    }); 
  } 
  iterate(0);                                              //[4] 
} 

function iterate(index) { 
  if(index === tasks.length)  { 
    return finish(); 
  } 
  const task = tasks[index]; 
  task(function() { 
    iterate(index + 1); 
  }); 
} 
 
function finish() { 
  //iteration completed 
} 
 
iterate(0); 

iterateSeries(collection, iteratorCallback, finalCallback) 

Our web spider application seems like a perfect candidate to apply the concept of parallel execution. So far, our application is executing the recursive download of the linked pages in a sequential fashion. We can easily improve the performance of this process by downloading all the linked pages in parallel.

To do that, we just need to modify the spiderLinks() function to make sure to spawn all the spider() tasks at once, and then invoke the final callback only when all of them have completed their execution. So let's modify our spiderLinks() function as follows:

function spiderLinks(currentUrl, body, nesting, callback) { 
  if(nesting === 0) { 
    return process.nextTick(callback); 
  } 
  const links = utilities.getPageLinks(currentUrl, body); 
  if(links.length === 0) { 
    return process.nextTick(callback); 
  } 
 
  let completed = 0, hasErrors = false; 
 
  function done(err) { 
    if(err) { 
      hasErrors = true; 
      return callback(err); 
    } 
    if(++completed === links.length && !hasErrors) { 
      return callback(); 
    } 
  } 
 
  links.forEach(link => { 
    spider(link, nesting - 1, done); 
  }); 
} 

Let's explain what we changed. As we mentioned earlier, the spider() tasks are now started all at once. This is possible by simply iterating over the links array and starting each task without waiting for the previous one to finish:

  links.forEach(link => { 
    spider(link, nesting - 1, done); 
  }); 

Then, the trick to make our application wait for all the tasks to complete is to provide the spider() function with a special callback, which we call done(). The done() function increases a counter when a spider task completes. When the number of completed downloads reaches the size of the links array, the final callback is invoked:

function done(err) { 
  if(err) { 
    hasErrors = true; 
    return callback(err); 
  } 
  if(++completed === links.length && !hasErrors) { 
    callback(); 
  } 
} 

With these changes in place, if we now try to run our spider against a web page, we will notice a huge improvement in the speed of the overall process, as every download is carried out in parallel without waiting for the previous link to be processed.

Also, for the parallel execution flow, we can extract our nice little pattern, which we can adapt and reuse for different situations. We can represent a generic version of the pattern with the following code:

const tasks = [ /* ... */ ]; 
let completed = 0; 
tasks.forEach(task => { 
  task(() => { 
    if(++completed === tasks.length) { 
      finish(); 
    } 
  }); 
}); 
 
function finish() { 
  //all the tasks completed 
} 

With small modifications, we can adapt the pattern to accumulate the results of each task into a collection, to filter or map the elements of an array, or to invoke the finish() callback as soon as one or a given number of tasks complete (this last situation in particular is called competitive race).

Running a set of tasks in parallel can cause issues when using blocking I/O in combination with multiple threads. However, we have just seen that in Node.js this is a totally different story; running multiple asynchronous tasks in parallel is in fact straightforward and cheap in terms of resources. This is one of the most important strengths for Node.js, because it makes parallelization a common practice rather than a complex technique to only use when strictly necessary.

Another important characteristic of the concurrency model of Node.js is the way we deal with task synchronization and race conditions. In multithreaded programming, this is usually done using constructs such as locks, mutexes, semaphores, and monitors, and it can be one of the most complex aspects of parallelization, which has considerable impact on performances as well. In Node.js, we usually don't need a fancy synchronization mechanism, as everything runs on a single thread! However, this doesn't mean that we can't have race conditions; on the contrary, they can be quite common. The root of the problem is the delay between the invocation of an asynchronous operation and the notification of its result. To make a concrete example, we can refer again to our web spider application, in particular, the last version we created, which actually contains a race condition (can you spot it?).

The problem we are talking about lies in the spider() function, where we check if a file already exists, before starting to download the corresponding URL:

function spider(url, nesting, callback) { 
  const filename = utilities.urlToFilename(url); 
  fs.readFile(filename, 'utf8', (err, body) => { 
    if(err) { 
      if(err.code !== 'ENOENT') { 
        return callback(err); 
      } 
 
      return download(url, filename, function(err, body) { 
//... 

The problem is that, two spider tasks operating on the same URL might invoke fs.readFile() on the same file before one of the two tasks completes the download and creates a file, causing both tasks to start a download. This situation is shown in the following diagram:

The preceding diagram shows how Task 1 and Task 2 are interleaved in the single thread of Node.js and how an asynchronous operation can actually introduce a race condition. In our case, the two spider tasks end up downloading the same file.

How can we fix that? The answer is much simpler than we might think. In fact, all we need is a variable to mutually exclude multiple spider() tasks running on the same URL. This can be achieved with some code such as the following:

const spidering = new Map(); 
function spider(url, nesting, callback) { 
  if(spidering.has(url)) { 
    return process.nextTick(callback); 
  } 
  spidering.set(url, true); 
 
//... 

The fix does not require many comments. We simply exit the function immediately if the flag for the given url is set in the spidering map; otherwise, we set the flag and continue with the download. For our case, we don't need to release the lock, as we are not interested in downloading a URL twice, even if the spider tasks are executed at two completely different points in time.

Race conditions can cause many problems, even if we are in a single-threaded environment. In some circumstances, they can lead to data corruption and are usually very hard to debug because of their ephemeral nature. So, it's always good practice to double check for this type of situation when running tasks in parallel.

We now present a pattern to execute a set of given tasks in parallel with limited concurrency:

const tasks = ... 
let concurrency = 2, running = 0, completed = 0, index = 0; 
function next() {                                             //[1] 
  while(running < concurrency && index < tasks.length) { 
    task = tasks[index++]; 
    task(() => {                                              //[2] 
      if(completed === tasks.length) { 
        return finish(); 
      } 
      completed++, running--; 
      next(); 
    }); 
    running++; 
  } 
} 
next(); 
 
function finish() { 
  //all tasks finished 
} 

This algorithm can be considered a mix between a sequential execution and a parallel execution. In fact, we might notice similarities with both the patterns we presented earlier in the chapter:

Pretty simple, isn't it?

Our web spider application is perfect for applying what we learned about limiting the concurrency of a set of tasks. In fact, to avoid the situation in which we have thousands of links crawled at the same time, we can enforce a limit on the concurrency of this process by adding some predictability on the number of concurrent downloads.

We could apply the pattern we just learned to our spiderLinks() function, but what we would obtain is only limiting the concurrency of a set of links found within one single page. If we chose, for example, a concurrency of 2, we would have at most two links downloaded in parallel for each page. However, as we can download multiple links at once, each page would then spawn another two downloads, causing the grand total of download operations to grow exponentially anyway.

class TaskQueue { 
  constructor(concurrency) { 
    this.concurrency = concurrency; 
    this.running = 0; 
    this.queue = []; 
  } 
 
  pushTask(task) { 
    this.queue.push(task); 
    this.next(); 
  } 
 
  next() { 
    while(this.running < this.concurrency && this.queue.length) { 
      const task = this.queue.shift(); 
      task(() => { 
        this.running--; 
        this.next(); 
      }); 
      this.running++; 
    } 
  } 
}; 

const TaskQueue = require('./taskQueue'); 
const downloadQueue = new TaskQueue(2); 

function spiderLinks(currentUrl, body, nesting, callback) { 
  if(nesting === 0) { 
    return process.nextTick(callback); 
  } 
 
  const links = utilities.getPageLinks(currentUrl, body); 
  if(links.length === 0) { 
    return process.nextTick(callback); 
  } 
 
  let completed = 0, hasErrors = false; 
  links.forEach(link => { 
    downloadQueue.pushTask(done => { 
      spider(link, nesting - 1, err => { 
        if(err) { 
          hasErrors= true; 
          return callback(err); 
        } 
        if(++completed === links.length && !hasErrors) { 
          callback(); 
        } 
        done(); 
      }); 
    }); 
  }); 
}