Lecture27 - Friday, May 29 Project #4 Due Wednesday, June 3...

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Friday, May 29 Project #4 Due Wednesday, June 3 before midnight Evaluation criteria are posted Questions / Comments? Do the Projects Survey Contribution credit Responses will be posted on the course wiki Today's topics Linux Virtual File System Intro to Synchronization Quiz #2 Virtual File Systems Subsystem of the OS that implements the file system interface for userspace Provides a set of system calls that work regardless of the "real" file system and underlying hardware File system should be transparent to users/applications open(), read(), write(), etc. Linux VFS Interface between the OS and the file systems as they exist on external devices. Implements generic calls to file I/O functions Hides differences in many supported devices and media All file systems implement basic structures and operations Some file systems may require additional features in order to be usable by the Linux VFS Linux VFS unix bias Supports other systems many require additional interfacing sysfs rootfs bdev proc sockfs binfmt_misc usbfs usbdevfs futexfs tmpfs rpc_pipefs eventpollfs devpts ext2 ext3 ext4 ramfs hugetlbfs iso9660 relayfs mqueue autofs nfs nfs4 ... and more Major VFS structures file dentry inode superblock File on disk: stream of bytes file structure: defined in <linux/fs.h> file structure represents an open file associated with a process in memory Similar to File Control Block Contains file perprocess information about file pointer to operations that manipulate a file pointers to file data stored in memory permissions, etc. read/write positions, etc. buffers, system perfile information, etc. dentry Component of a path dentry structure: defined in <linux/dcache.h> May be instantiated and cached as needed Contains directory name or file name not a full path name a directory is a file information about nodes in the file system's directory tree pointer to operations for dentry lookup etc. inode Stores one specific file's metadata Similar to Systemwide Openfile Table Copied to memory when file is first opened inode structure: defined in <linux/fs.h> Contains all information about a file pointer to operations that update the inode pointer to operations defined for the file structure etc. superblock Represents a specific mounted file system superblock structure: defined in <linux/fs.h> Contains pointer to operations that update the list of inodes etc. Other important VFS structures file_system_type structure defined in <linux/fs.h> contains pointer to function to get the superblock from the disk, etc. vfsmount structure defined in <linux/mount.h> acts as the mount point contains pointers to root, superblock for this file system, etc. Perprocess VFS structures files_struct structure defined in <linux/file.h> contains pointer to an array of open files for the process fs_struct structure defined in <linux/fs_struct.h> contains pointers to root, default directory, mount point, etc. Objects and Abstract Data Types Linux VFS defines certain structures and operations generically Structures contain pointers to structures of operations Structures of operations contain pointers to functions, etc. Objects and Abstract Data Types Function pointers point to functions implemented by the "real" file system File system types, I/O scheduling algorithms, etc. may be selected, enabled and built into kernel by boottime options on kernel command line default behaviors at file system mount time default overrides Objectorientation in Linux VFS (C) interface: struct contains class: implemented by assigning file system type instantiation: mounting a file system data fields (instance data) pointers to structs (generic data types) pointer to struct of function pointers (methods) function pointers reference actual file system functions Questions on Linux VFS? Introduction to Synchronization Cooperating Processes An independent process cannot affect or be affected by the execution of another process. Cooperating processes may affect each other Advantages of process cooperation Information sharing Computation speedup Modularity Convenience see discussion of parallelism Process Synchronization Concurrent access to shared data may result in data inconsistency. To maintain data consistency, must have mechanisms to ensure orderly execution of cooperating processes. ProducerConsumer Problem Paradigm for cooperating processes unboundedbuffer places no theoretical limit on the size of the buffer producer process produces data and sends it to a buffer consumer process takes data from the buffer Unbounded queue Circular queue boundedbuffer assumes that there is a fixed buffer size UnboundedBuffer SharedMemory Solution Shared data, initialization struct { . . . } item; queue q = create_q(); Producer Process UnboundedBuffer item nextProduced(); while (1) { q.enqueue(nextProduced()); } Consumer Process item nextConsumed; while (1) { if (!q.empty()){ nextConsumed = q.front(); q.dequeue(); } } BoundedBuffer SharedMemory Solution Shared data, initialization #define BUFFER_SIZE 10 struct { . . . } item; item buffer[BUFFER_SIZE]; int in = 0; int out = 0; BoundedBuffer SharedMemory Solution Buffer is implemented as a circular queue. (in == out) indicates empty buffer. indicates full buffer. Solution is correct, but can only use BUFFER_SIZE1 elements (((in + 1) % BUFFER_SIZE) == out) BoundedBuffer Producer Process item nextProduced(); while (1) { while (((in + 1) % BUFFER_SIZE) == out) ; /* buffer full - do nothing */ buffer[in] = nextProduced(); in = (in + 1) % BUFFER_SIZE; } BoundedBuffer Consumer Process item nextConsumed; while (1) { while (in == out) ; /* buffer empty - do nothing */ nextConsumed = buffer[out]; out = (out + 1) % BUFFER_SIZE; } Process Synchronization Sharedmemory solution to boundedbuffer problem allows at most n 1 items in the buffer. One way to use all spaces in the buffer: modify the producerconsumer code by adding a variable counter initialized to 0 incremented each time a new item is added to the buffer decremented each time an item is removed from the buffer counter == 0 means buffer is empty counter == BUFFER_SIZE means buffer is full BoundedBuffer Shared memory with counter Shared data, initialization #define BUFFER_SIZE 10 typedef struct { . . . } item; item buffer[BUFFER_SIZE]; int in = 0; int out = 0; int counter = 0; BoundedBuffer Producer process item nextProduced(); while (1) { while (counter == BUFFER_SIZE) ; /* do nothing */ buffer[in] = nextProduced(); in = (in + 1) % BUFFER_SIZE; counter++; } BoundedBuffer Consumer process item nextConsumed; while (1) { while (counter == 0) ; /* do nothing */ nextConsumed = buffer[out]; out = (out + 1) % BUFFER_SIZE; counter--; } BoundedBuffer Parts of each function must be performed atomically. Atomic operation Critical section ... an operation that completes in its entirety without interruption. Some may be implemented in hardware Otherwise, CPU scheduler may switch context before the operation is complete One of the problems: Interleaving If both the producer and consumer attempt to update the buffer concurrently, the assembly language statements may get interleaved. Interleaving depends on how the producer and consumer processes are scheduled by the CPU scheduler. Example The statement "count ++" may be implemented in assembly language as: register1 = counter register1 = register1 + 1 counter = register1 The statement "count " may be implemented as: register2 = counter register2 = register2 1 Example Assume counter is initially 5. Assembly level statements might get interleaved as: producer: register1 = counter (register1 = 5) producer: register1 = register1 + 1 (register1 = 6) consumer: register2 = counter (register2 = 5) consumer: register2 = register2 1 (register2 = 4) Race Condition When two or more processes access and manipulate shared data concurrently, and the final value of the shared data depends on which process finishes last ... a race condition exists. To prevent race conditions, concurrent processes must be synchronized Debugging is difficult, because the particular context switch that caused the race condition may not be reproducible To be continued ... Questions? Read Love Chapter 8 Quiz #2 Do the Projects Survey ...
View Full Document

This note was uploaded on 06/28/2009 for the course CS 411 taught by Professor Staff during the Spring '08 term at Oregon State.

Ask a homework question - tutors are online