This directory contains three examples of threading & primitives in Chromium's//base library that build off of the basiccpp101threading and task runner introduction. In particular, these examples aim to give more insight into how task scheduling works by introducingTaskQueue as the basic unit of scheduling, and showing how multipleTaskQueues can interact within the same thread and across threads.
Additionally, these examples show direct usage of some of the foundational scheduling primitives in//base as they would be used in any program, to demystify their usage and help illustrate how core pieces of Chromium work under the hood.
These examples offer a deep dive into the threading & scheduling machinery that Chromium developers will rarely interact with directly. In practice, much of Chromium's threading & scheduling is exposed through things likebase::ThreadPool,base::SequencedTaskRunner::GetCurrentDefault(), orExecutionContext::GetTaskRunner() in Blink, etc.
This first example is the simplest, but illustrates direct usage of the following task scheduling primitives:
SequenceManager(Impl)MessagePumpTaskQueue /TaskRunnerRunLoopThis example goes further than the ones incpp101/, as those defer the setup of the main thread scheduling infra tobase::test::TaskEnvironment, whereas this example shows how to manually use such infrastructure and customize it accordingly.
This example shows howTaskQueues allow a thread to multiplex many sources of tasks. This effectively means that eachTaskQueue is a “sequence”, allowing the same physical thread to host multiple sequences that can be scheduled independently. This is an inversion from the standard usage of “sequence”, which often involves a sequential ordering of tasks that may opaquely span multiple physical threads.
This example works by creating twoTaskQueues with different priorities to show that the orderingacross queues is not guaranteed, while the ordering of non-delayed taskswithin a queue — regardless of whichTaskRunner is used to post the task — is always FIFO order.
(Requires DCHECKs to be enabled to build. Either setis_debug = true ordcheck_always_on = true in your gn args).
This example is similar to the previous one, however we schedule two identical-priorityTaskQueues independently from each other using arandomized task selection seed option exposed via theSequenceManager API. This shows that in our contrived example, orderingacross queues of the same priority is not guaranteed to be in FIFO task posting order, while the ordering of non-delayed taskswithin the same queue isstill always FIFO order.
Note that in practice and by default, the ordering of tasksacross task queues with the same priorityis in fact guaranteed to be in FIFO posting-order because legacy code has come to depend on this behavior, although it should not be relied upon, as queues can dynamicallychange priority and getfrozen/unfrozen arbitrarily.
So far the threading and task posting examples have been either single-threaded, or utilize the thread pool. But in Chromium, especially in renderer processes, it‘s common to post tasks on specific threads that the platform maintains. That’s exactly what the scenario that this example reproduces. First we setup the main thread task scheduling infra, and then spin up a newbase::Thread which represents a new physical thread. Then we explicitly post tasks back and forth between the main and secondary thread, via a cross-threadTaskRunner.