Brock-Nannestad, Laust

Karlsson, Sven

Online Research Database In Technology

                       General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.  • Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain • You may freely distribute the URL identifying the publication in the public portal   If you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediately and investigate your claim.     Downloaded from orbit.dtu.dk on: Dec 20, 2017Safe Asynchronous System Calls - extended abstractBrock-Nannestad, Laust; Karlsson, SvenPublication date:2014Document VersionPublisher's PDF, also known as Version of recordLink back to DTU OrbitCitation (APA):Brock-Nannestad, L., & Karlsson, S. (2014). Safe Asynchronous System Calls - extended abstract. Abstractfrom International Symposium on Code Generation and Optimization, CGO 2014, Orlando, Florida, UnitedStates.Safe Asynchronous System Callsextended abstractLaust Brock-Nannestad and Sven KarlssonNovember 15, 20131 IntroductionThe typical interface between applications and the operating system is thesystem call or trap. It allows the application to request a service of theoperating system. To handle the trap, the processor switches from the un-privileged mode of the application to the privileged mode of the kernel, whothen handles the call. While the kernel handles the call, the caller is blockedand does not execute. Non-blocking calls which return before the operationhas completed exist, for example the aio calls on UNIX systems, but arestill implemented using the trap mechanism. Non-blocking calls expose someamount of parallelism in the caller, but each call incurs an overhead as theoperating system saves and restores the context of the processor wheneverit interrupts the application.The individual nature of system calls makes them prone to program-ming errors and there is a long history of race condition exploits and filelocking schemes used especially by mail systems. Many of these problemscan be prevented if sequences of operations can be composed and executedatomically.2 DesignWe propose an alternate way of performing system calls with an asyn-chronous interface. We replace the traditional system call mechanism witha pair of queues implemented in shared memory. The caller sends packetsconveying the same information as normal system calls. The operating sys-tem in turn polls this queue and executes the calls. Responses from the OSflow in the opposite direction using a similar queue. The queues provide an1asynchronous interface allowing the caller to enqueue operations and con-tinue with other work while they are executed. This is illustrated in figure1.Figure 1: An application thread and the operating system communicatethrough shared queues.The caller may depend on the result of an operation before it can con-tinue. Rather than busy waiting, we introduce a barrier. Like a memorybarrier it blocks the caller until all preceding system calls have completed.The barrier may be implemented as a trap or it may simply relinquish exe-cution to a user mode scheduler.To safely allow the grouping of related operations, we borrow the conceptof transactions from database systems [2]. We encapsulate sequences of sys-tem calls as transactions and rely on the OS to ensure that each transactioneither completes successfully or not at all and that concurrent transactionsdo not interfere. The OS is responsible for detecting conflicts and informingthe caller of the failed transaction.Figure 2 shows a code fragment implemented using traditional blockingsystem calls and with our approach. send and get are non-blocking opera-tions on the queue. Conventional system call traps are highlighted in bold.begin and commit encapsulate the set of system calls inside a transaction.3 Related workThe overhead introduced by frequent context switches has been investigatedin the areas of inter-process communication and system calls. Shared mem-ory buffers for efficient communication between processes was suggested byBershad et al. [1]. Several scalable research operating systems, such asBarrelfish and fos, employ this technique.Libflexsc by Soares and Stumm [4] implements asynchronous system callson top of Linux. Instead of a queue they allocate an array of system callcontexts in shared memory. The caller scans for a free context and writes2i n t fd=open(" t e s t . txt ")i n t ∗addr=mmap( fd , "RW")∗addr = 128msync( addr )close ( fd )(a) Trap basedsend ( begin )send ( open (" t e s t . txt " ) )barrier ( )i n t fd = get ( )send (mmap( fd , "RW"))barrier ( )i n t ∗addr = get ( )∗addr = 128send (msync ( addr ) )send ( c l o s e ( fd ) )send ( commit )barrier ( )(b) Queue basedFigure 2: Pseudocode for traditional and queue based calls. Trap based callsare marked in bold.a system call into it. The kernel periodically scans contexts, finding newsystem calls to execute, and replacing the context with the result once done.Their experiments found that removing context switches primarily avoideddata cache pollution.Encapsulating system calls in transactions has been explored by Porteret al. in TxOS [3]. TxOS implements transactional system calls on top of theLinux kernel with an acceptable overhead. The implementation retains thetrap-based interface and requires a context switch for each call even insidetransactions.4 ConclusionThis abstract proposes an asynchronous transactional system call interface.An implementation effort is underway on top of a small operating system.An evaluation will show if the removal of context switches, but addition oftransaction overhead, remains acceptable.References[1] Brian N. Bershad et al. User-level interprocess communication for sharedmemory multiprocessors. ACM Transactions on Computer Systems, 9(2),1991.3[2] Jim Gray et al. The transaction concept: Virtues and limitations. InVLDB, volume 81, 1981.[3] Donald E. Porter et al. Operating system transactions. In Proceedingsof the ACM SIGOPS 22nd symposium on Operating systems principles.ACM, 2009.[4] Livio Soares and Michael Stumm. Exception-less system calls for event-driven servers. In Proc. of USENIX Annual Tech. Conf, 2011.4

Safe Asynchronous System Calls - extended abstract

http://orbit.dtu.dk/ws/files/102420101/cgo_abstract.pdf

Safe Asynchronous System Calls - extended abstract

Abstract

Similar works

Full text

Available Versions

Online Research Database In Technology