27. 02. 2015

Improving Microkernel Construction through Hardware Transactional Memory


Till Smejkal

TU Dresden


Starting with the introduction of multi-core and many-core systems, the need for parallelizable programs got more important. Programmers of normal applications and especially of operating system kernels had to invent techniques to make their programs able to correctly run in parallel on multiple processor cores. Therefore, mechanisms such as locks and semaphores have been used to protect internal data structures against corruption due to parallel accesses. Unfortunately, these techniques have significant drawbacks, which make the development with them difficult and cumbersome.

In this talk, I determine and discuss whether a novel technique for parallel programming called hardware transactional memory can influence the design and construction of a microkernel. Hardware transactional memory allows programmers to define regions in their code as critical, which are then executed by the processor in a transactional fashion. This means, that this section is executed atomically (It either runs until completion or not at all.) and in full isolation (It is not possible for any other processor core to read memory values written within this section.).

Using these properties, I reworked the IPC system call of the Fiasco.OC microkernel. My implementation not only reduces the code complexity of the IPC path, but also improves the overall performance of it up to a factor of four, compared to the original version.

27. 02. 2015

IPC Message Logging and Replaying


Sven Dziadek

TU Dresden


Programs can go wrong. Independent of how to recognize faults, faults have to be handled. One possibility is to restart the faulty program. This works very well for programs with none or only few interconnections. Restarting a server application resets the communication channels to a lot of clients, which have to be restarted, too.

To circumvent the transitive restart of all dependent processes, an IPC message logging and replaying mechanism is presented. Our approach logs all Inter-Process-Communication (IPC) messages between the last checkpoint and a possible crash. If a crash occurs, the last checkpoint is loaded and the server receives the messages from the log to bring the server into a consistent state with its clients. After the server application has reached the point in execution where it failed, the following IPC messages are logged and forwarded to the other applications again.
28. Oct 2020
· Copyright © 2001-2022 Operating Systems Group, TU Dresden | Impressum ·