150 likes | 301 Views
Geoffrey Trujillo CSE 430. Operating System Transactions. Problem. POSIX system calls do not handle concurrency well Only one system call can be guaranteed to execute atomically System cannot remain consistent when multiple system calls are made
E N D
Geoffrey Trujillo CSE 430 Operating System Transactions
Problem • POSIX system calls do not handle concurrency well • Only one system call can be guaranteed to execute atomically • System cannot remain consistent when multiple system calls are made • No simple implementation can be made with locks
Problem • Time-of-check-to-time-of-use • Securty risk • Race condition • Consistency of file system • Updates • Installations
Operating System Transaction • Easier to use than locking mechanism • Eliminate race condition • Time-of-check-to-time-of-use • Able to maintain consistency • Use of concurrent application • Software installation • Software update • Isolated from system until commit
System Transaction Use • Commands • sys_xbegin, sys_xend, sys_xabort • Use • sys_xbegin(); • //stuff • sys_xend();
Race Condition Locks if ( access (‘foo’) { symlin(‘secret’, ‘foo’); fd = open(‘foo’); write(fd); }
Race Condition Transaction sys_xbegin(); if ( access (‘foo’) { symlink(‘secret’, ‘foo’); fd = open(‘foo’); write(fd); } sys_xend(); symlink(‘secret’, ‘foo’);
Install/Update Consistency sys_xbegin(); //install or //update sys_xend(); • Will have comlete install or update else will have original system
How Transactions Work • Broken into two segments • Header • The stable part that holds the pointer to data • Data • The part the hold the private copy of the data in the system header Data
How Transactions Work Header Lock Private Copy Data
How Transactions Work Header Data
Performance • 500,000 renames