Topsy Compendium. Threads Topsy is a multi-threaded operating system (i.e. multiple threads are able to run quasiparallel)

Transkript

1 Topsy Compendium Martin Wirz Overview Characteristics Threads Topsy is a multi-threaded operating system (i.e. multiple threads are able to run quasiparallel) Process: a program in execution Threads, however, share their resources, in particular they run in the same address space. The user process as well as the kernel process contain several threads each All threads of a specific process are running in one address space. Synchronization of shared memory is accomplished via messages. Memory I/O Topsy divides the memory into two address spaces: one for user threads and one the other for the the OS kernel The memory is organized in paged manner, i.e. the whole address space is split up into blocks of predefined size. No swapping of pages to secondary memory is supported Threads can allocate memory by reserving a certain, connected piece of the virtual address pace. (Remeber, the physical memory doesen t need to be connected since there s a page table to control the handling. The I/O Subsystem provides a framework for writing and installing hardware device drivers System structure Strict modular structure (It s not OOP!) The kernel contains three main modules: 1. memory manager 2. thread manager 3. I/O subsystem 1

2 All kernel modules are implemented as threads and therefore preemptable (i.e. they can be interrupted like user threads) Modules Memory Manager Module The memory manager is responsible to execute the memory demands of kernel and user thread: allocating and deallocating virtual memory regions. Thread Manager Module Thread scheduler uses fifo scheduling for non-preemptive (can t be contolled by the thread manager while running) threads and round-robin for preemptive (can be contolled by the thread manager while running) scheduling. Interprocess communication (IPC) is based on message passing. I/O Subsystem Module IOMain covers the message dispating (for opening and closing devices). IODevice represents a generic driver (a framework for device drivers). Drivers contains de drivers driver modules. (see fig) Topsy Module A collection of routines used by various kernel components. syscall is the only modul in the Topsy modul which is used by user and kernel likewise. System Call Interface System calls (for short: syscalls) provide the interface between a user thread and the Topsy operating system. 2

3 Memory Management SyscallError vmalloc(address *addressptr, unsigned long int size); Allocate Memory SyscallError vmfree(address address); deallocates a region which has been reserved earlier Thread Management SyscallError tmmsgsend(threadid to, Message *msg); expects a destinatino and a message SyscallError tmmsgrecv(threadid* from, MessageId msgid, Message* msg, int timeout); for receiving a message. It must be specified from which thread a message should be received (ANY is possible), which kind of message is waited for (ANYMSG is possible) and which amount of time should be waited (infinite is standard) SyscallError tmstart(threadid* id, ThreadMainFunction mainfunction, ThreadArg parameter, char *name); srart a new thread void tmkill(threadid id); a thread wants to kill another void tmexit(); a thread wants to finish its own execution void tmyield(); used by non-preemptive scheduling. It yiels the control to another thread if there is one ready to run, otherwise the calling thread regains control (CUP) (i.e. continuous execution). In the preemptive case, the CPU is automatically assigned to threads (round robin). I/O Interface SyscallError ioopen(int devicenumber, ThreadId* id); Open a device SyscallError ioclose(threadid); Close a device SyscallError ioread(threadid id, char* buffer, unsigned long int* nofbytes); Read from a device SyscallError iowrite(threadid id, char* buffer, unsigned long int* nofbytes); Write to a device SyscallError ioinit(threadid); Initializing a device for the first time 3

4

5 Device Driver Beispiel Mouse Device Die Mouse speicher Hardwaredaten in einem eigenen Registerfeld (Device-Register-Block). Dies ist in der IODevcDesc-Struktur gespeicher als Pointer auf die Registerstartadresse. Zugreiffen kann man also via base und einem Adressoffset. Dies nennt man auch Memory Mapped IO, weil das Device über eine Speicheradresse angesprochen werden kann. Adressoffset Read Write CONTROL_REGISTER RKEY_REGISTER RX_REGISTER RY_REGISTER RESET_REGISTER Key-Id relativ in x-richtung relatv in y-richtung Reset interrupt Control Reg Typdef struct IODeviceDest_t { Address base; void* extensions; Readfunktion mouse_read(...); InterruptHandler mouse_interrupthandler(...); } IODeviceDesc; Dies ist die allgemeine Treiberspezifikation, wie sie für jeden einzelnen Treibertyp im System gespeichert ist. Typedef struct IODeviceDest_t* IODevice; Pointer auf allgemeine Treiberspezifikation für einfaches Handling. Typedef struct devmousedesc_t { short Key_id; short x; short y; } devmousedesc; Treiberspezifische Spezifikation Hier können Erweiterungen angebracht werden, welche der Treiber benötigt. E.g. Speicher für Memory-Mapped-IO-Registerfeld, eigene Funktionen etc. Dient der Kommunikation zwischen dem Interrupthandler und den Treiberfunktionen. Dies ist quasi die softwaremässige Beschreibung des Treiber, damit nicht jede Treiberfunktion auf die Hardware zugreiffen muss, sondern nur der Interrupt Handler. typdef devmousedesc* devmouse; Pointer auf erweiterten Treiberspezifikation für einfaches Handling.

6 ERROR mouse_read(iodevice this, ThreadId threadid, char* buff, long int* size) { *size = sizeof(devmousedesc); memcpy(buffer,this->extension,*size); bzero(this->extension,*size); return IO_READOK; } Liest die vom Interrupt handler gelieferten Daten via extensions aus. Danach setzt er den Speicher zurück. Void mouse_interrupthandler(iodevice this) { devmouse mouse; mouse = (devmouse)this->extension; mouse->key_id = *((short*)(this->base + RKEY_REGISTER)); mouse->x = *((short*)(this->base + Rx_REGISTER)); mouse->y = *((short*)(this->base + Ry_REGISTER)); int z = *((char*)(this->base + RESET_INTERRUPT)); } Der Mouse-Treiber generiert einen Interrupt für jede Bewegung mit der Maus und für jedes Drücken und Loslassen einer Taste der Maus. Mit einem Dummy-read auf Register RESET_INTERRUPT wird das Interrupt-Signal zurückgesetzt. Sobald nun also ein Interrupt geschieht, wird die Funktion mouse_interrupthandler aufgerufen. Die Hardware hardware hat die Daten in den entsprechenden Registern abgelegt und der Interrupt handler liest sie aus, speichert sie im erweiterten driver-spezifischen struct, welches über extension angesprochen werden kann. Dann wird der Interrupt zurückgesetzt und die Hardware kann eine neue Mousebewegung erkennen. Wie wird jetzt aber auf die generierten Daten zugegriffen? Via der mouse_read-funktion! Dazu ist ein blockierender Read-Systemaufruf sinvoll. mouse_read-systemaufruf soll blockiert werden, falls noch keine neuen Mousdaten vorhanden sind, sonst muss der Thread/Prozess, der die Mousekoordinaten lesen muss ein polling machen, was Systemresourcen verschwendet, wenn noch keine Bewegung der Mouse registriert wurde. Es gibt 2 Varianten dies zu realisieren: a) Read-Prozedure hat eine Schleife (busy waiting) bis Daten vom Interrupt gespeichert werden (evtl Synchronisation). Wenn man annimmt, dass Mousebewegungen sehr häufig geschehen, ist busy waiting schneller. b)synchronisation zwischen Interrupthandler und read-prozedure durch MsgSend() und MsgRecv() Mechanismen (Topsy) oder andere Synchronisationsmechanismen (Semaphoren). In der Zeit, in der gewartet wird, können andere Aufgaben erledigt werden. Zur Erinnerung: Bei MsgRecv() und bei Semaphoren wird der Prozess nicht in eine Endlosschleife versetzt, bis Ereignis geschieht, sondern von einem übergeordneten Manager in eine waiting(queue) gefüttert, bis Ereignis eintrifft. Dies ist Resourcenschonend, braucht aber etwas länger, bis Prozess bei wieder in Ausführung versetzt wird.