Download Text - Barrelfish

Chapter 4
Implementation
This chapter gives an overview of how we implemented the Octopus service
in Barrelfish. We also show how we used the Octopus API, described in
Chapter 3, to build distributed locks, barriers and semaphores.
4.1
Octopus Architecture
Figure 4.1 gives an overview of our architecture. As we already mentioned
briefly in Section 3.1, our server is built on top of the SKB. To translate
records and queries into Prolog from the language we introduced in Section 3.2, we needed a lexer and parser. We built the lexer and parser using
Flex [25] and Bison [23]. The parser is used by liboctopus_server to generate an abstract syntax tree for record queries sent to the server, but also by
the clients to read data from records received from the server. Using a designated parser also leads to a clean interface with the SKB: In case we send
a request to the server, liboctopus_server is responsible for parsing the incoming request. The resulting abstract syntax tree (AST) is then passed on
to the SKB, which translates the AST into a Prolog query and executes the
query, using our storage implementation written in Prolog.
4.2
Client–Server Connection
In Figure 4.1, we see that a client has two connections to the server: a regular
Flounder binding (referred to as the event binding) to receive asynchronous
events (namely trigger events and published records) and a THC binding
used for all communication from client to the server. A client talks to the
server by using remote procedure calls (RPC). The THC and the event binding use the same Flounder interface. This design has the advantage that a
21