Application‐specific thread schedulers for internet server applications

Abstract

SUMMARYThis paper describes CATAPULTS (Creating And Testing APplication-specific User Level Thread Schedulers), a domain-specific language for creating and testing application-specific user-level thread schedulers. Using a domain-specific language to write user-level thread schedulers provides three advantages. First, doing so modularizes the thread scheduler, making it easy to plug in and experiment with different thread scheduling strategies. Second, using a domain-specific language for scheduling code helps prevent several of the common programming mistakes that are easy to make when developing thread schedulers. Finally, the CATAPULTS translator has multiple backends that generate code for different languages and libraries. This makes it easy to prototype an application in a high-level language and then later port it to a low-level language; the CATAPULTS translator will take care of generating the appropriate code for both the prototype and the final version of the program from a single scheduler specification. This paper describes how we have used CATAPULTS to improve the performance of two important and representative Internet server applications.

Application‐specific thread schedulers for distributed applications

“…All of these cooperating subschedulers are able to communicate and share various global scheduling data. Distributed nodespec schedulers are syntactically identical to classic CATAPULTS schedulers; any classic scheduler can be used as a nodespec scheduler without modification. Variables defined in a nodespec's data section are referred to as node global variables .…”

“…Section 2.1 introduced nodespecs and master schedulers. As described there, nodespecs are just classic CATAPULTS schedulers, an example of which was illustrated in Figure and are described in detail in . So, here, we describe only the CATAPULTS language mechanisms for master schedulers.…”

“…However, other applications may not know how many nodes will be present while the application executes, or nodes may join and leave the application. In these cases, nodes may be organized into simple collections (stacks and queues) just as threads in a classic scheduler or node scheduler may be organized into collections (see ). Although nodes may also be placed into pstacks and pqueues that are sorted based on the value of node global variables, these containers will not be resorted when the node global variables change value.The declaration of nodes in a distributed scheduler closely mirrors the declaration of threads in a classic CATAPULTS scheduler (see ).…”

“…In the previous work, we developed CATAPULTS ( C 128reating A 128nd T 128esting AP 128plication‐specific U 128ser L 128evel T 128hread S 128chedulers), our system for developing application‐specific schedulers. Our paper reports on the design and implementation of CATAPULTS and experience using CATAPULTS for real‐world internet server applications. CATAPULTS uses a domain‐specific language in which users can express how to schedule the threads in their applications.…”

“…The term ‘CATAPULTS’ in this paper refers to our extended version of CATAPULTS for distributed applications. The term ‘classic CATAPULTS’ refers to our nondistributed version described in our paper .…”