Development of a Resource Locking Algorithm for a Kernel

Debugging User-space API Library

TJHSST Computer Systems Lab2004-2005

Timothy Wismer

Introduction: Kernel-space and User-space

● The Linux Kernel provides the core functionality of a system—interaction with hardware, management of file systems, etc.

● All other programs depend on the functionality provided by the kernel, and are said to exist in user-space.

● Because of the critical position of the kernel, development and testing is very difficult.

● This project aims to simplify kernel development by moving kernel functionality to user-space.

Operating System Layers

Hardware Layer (ex: Matrox Millenium II Graphics Card)

Hardware Layer (ex: matroxfb_base.o driver)

Abstraction Layer (ex: framebuffer)

User-space (ex: OpenGL Library)

Kernel-space

Functionality to be ported by KDUAL

Introduction: Resource Locking

● Access to resources used by multiple processes must be atomic to avoid problems.

● Atomicity means that the entire operation succeeds or fails as a whole, and creates no intermediate state visible to other processes.

● A series of operations is made atomic by restricting those operations with a single, inherently atomic operation—the lock.

● As long as all processes use the lock to access the resource, they should not conflict.

Introduction: Deadlock

● Deadlock occurs when a process tries to obtain a resource that will not be available until the process gives up a resource that it already holds.

● Deadlock can involve any number of processors.● Deadlock cannot resolve on its own—unless

interrupted by some outside entity, it will cause the system to lock up.

● The KDUAL locking implementation will include deadlock detection.

Theory: Detection of Deadlock

● When processes are waiting on held locks, they depend on the process that holds the lock. If A depends on B and B depends on C, A also depends (indirectly) on C.

● Deadlock occurs when a process depends on itself (through any number of intermediaries).

● In a graph with nodes representing processes and edges representing dependencies, a deadlock will appear as a cycle: a complete path from a node back to itself.

A Deadlock Scenario

2

1,3

3

2

Each box represents a lock, held by the process identified in the oval. The inner box identifies processes waiting for the lock: Processes 2 and 3 each want the lock held by the other; process 1 is not part of the deadlock.

Wait-For Graph

1

2

3

The WFG representation of the previous slide. The cycle clearly shows a deadly embrace involving processes 2 and 3:

The Deadlock Detection Algorithm

● A separate Deadlock Detection Thread (DDT) will be created when the application starts.

● The locking functions will make information about process dependencies available to the DDT.

● The DDT will periodically check the dependency information for WFG cycles to identify deadlocks.

● In the event that a deadlock is detected, one involved process will be terminated and the user will be provided with debugging information.

Future Development & Value to Others

● Completion of KDUAL – so far the locking implementation is the only component; much more would be needed to make KDUAL usable.

● A working KDUAL would simplify and speed up development of kernel code.

● Apart from KDUAL, the locking implementation can serve as a “test suite” for applications that use locking.