📄 00000009.htm
字号:
<?xml version="1.0" encoding="gb2312"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=gb2312"/><title>关于实时扩展POSIX.1b turbolinux </title></head><body><center><h1>BBS 水木清华站∶精华区</h1></center><a name="top"></a>发信人: plato (纯真年代), 信区: Embedded <br />标 题: 关于实时扩展POSIX.1b <br />发信站: BBS 水木清华站 (Tue Apr 24 22:22:05 2001) <br /> <br />A Vision for Linux 2.2 -- POSIX.1b Compatibility and Real-Time Support <br />---------------------------------------------------------------------- <br />Markus Kuhn -- 1996-07-22 <br />[The latest version of this text can be found on <URL:<a href="ftp://">ftp://</a> <br />ftp.informatik.uni-erlangen.de/local/cip/mskuhn/misc/linux-posix.1b>.] <br />Today, the Linux kernel and libc are quite well compatible with the <br />POSIX.1 and POSIX.2 standards, which specify system calls, library <br />functions and shell command compatibility for UNIX-style operating <br />systems. Some Linux distributions have even passed POSIX.1 conformance <br />tests. However, the POSIX.1 system calls and library functions define <br />only a minimum core functionality required by anything that looks like <br />UNIX. Many slightly more advanced functions like mmap(), fsync(), <br />timers, modifiable scheduling algorithms, IPC, etc., which are <br />essential for many real world applications, have not been standardized <br />by POSIX.1 in 1990. <br />The new POSIX.1b standard (now officially called IEEE Std <br />1003.1b-1993, ISBN 1-55937-375-X, during development of the standard, <br />it was called POSIX.4) corrects this and I believe POSIX.1b contains a <br />large number of useful ideas for further development on Linux. <br />In the very short introduction below, I hope to rise your interest in <br />POSIX.1b and in real-time problems in general and to stimulate some <br />development work in this direction. Happy reading! <br />The new POSIX extensions focus on the requirements of real-time <br />applications and on applications which have to perform high <br />performance I/O. Many applications like interactive video games, high <br />performance database servers, multimedia players and control software <br />for all kinds of hardware require more deterministic scheduling, <br />paging, signaling, timing and inter process communication mechanisms <br />than what is available on traditional UNIX systems like BSD4.3. The <br />functionality of systems like BSD4.3 has been optimized with mainframe <br />multi-user time-sharing scenarios in mind, while operating systems for <br />personal computers should also support real-time applications in <br />addition. On a personal computer, it is often acceptable and desired <br />that for example interactive games or CPU and memory intensive <br />multimedia applications are excluded from the normal paging and <br />scheduling strategies that try to be as fair as possible to all users <br />of a large mainframe. <br />The lack of real-time capability in Linux 1.2 has so far been the main <br />reason why still a number of interesting applications that run fine on <br />MS-DOS were unimplementable as user processes under Linux. Some <br />examples are for instance highly reliable audio recording/replay <br />tools, control software for astronomical CCD cameras, real-time signal <br />processing algorithms, serial port smartcard emulators, MIDI computer <br />music tools, etc. With the recent addition of POSIX.1b memory locking <br />and static priority scheduling functions to Linux 1.3, this starts to <br />change now. A lot of things still have to be implemented and your <br />contributions are very welcome! This text summarizes, what functions <br />have not yet been implemented and which people have already started to <br />work on some of these. Please contact them if you want to know the <br />status of their work or if you want to contribute. Please let me know <br />about any progress so that I can keep this text up-to-date. <br />In order to use the first new POSIX.1b features that have recently <br />been added to Linux, please install a recent kernel, libc-5.3.12, and <br />man-pages-1.11 or newer as available via ftp from sunsite.unc.edu or <br />tsx-11.mit.edu. The real-time-support is far from complete, but some <br />interesting features are already available. <br />POSIX.1b-1993 defines in addition to POSIX.1-1990 the following new <br />concepts and functions: <br />Improved Signals <br />---------------- <br />POSIX.1b adds a new class of signals. These have the following new <br />features: <br />- there are much more user specified signals now, not only SIGUSR1 <br />and SIGUSR2. <br />- The additional POSIX.1b signals can now carry a little bit data (a <br />pointer or an integer value) that can be used to transfer to the <br />signal handler information about why the signal has been caused. <br />- The new signals are queued, which means that if several signals of <br />the same type arrive before the signal handler is called, all of <br />them will be delivered. <br />- POSIX.1b signals have a well-defined delivery order, i.e. you can <br />work now with signal priorities. <br />- A new function sigwaitinfo() allows to wait on signals and to <br />continue quickly after the signal arrived with program execution <br />without the overhead of calling a signal handler first. <br />The new queued signals are a necessary prerequisite for the <br />implementation of the POSIX.1b asynchronous I/O interface (see below). <br />They might also provide a good interface for delivering hardware <br />interrupts to user processes. <br />New functions for signals are: <br />sigwaitinfo(), sigtimedwait(), sigqueue(). <br />Implementation status: not yet implemented. Kevin Tran <br /><<a href="mailto:ttran@cs.UCR.edu>">ttran@cs.UCR.edu></a> has sent me a short note that he has started to do <br />some work on POSIX.1b signals for Linux. <br />Inter Process Communication (IPC) and memory mapped files <br />--------------------------------------------------------- <br />POSIX.1b now defines shared memory, messages, and semaphores. The <br />functionality and design of these is similar or better than the System <br />V IPC mechanisms which we have already in Linux. The major extensions <br />compared to System V IPC are: <br />- Strings (like filename paths) instead of integers are used now to <br />identify IPC resources. This will allow to avoid IPC resource <br />collisions much easier than in SysV IPC. The POSIX IPC name space <br />should probably be made visible as a /proc/ipc subdirectory, such <br />that the usual tools like ls and rm can be used to locate and <br />remove stale persistent IPC resources. <br />- Semaphores come in two flavors: kernel based semaphores (as in <br />System V, which requires a system call for each P/V operation) and <br />now also user memory based semaphores. Kernel based semaphores are <br />sometimes necessary for security reasons, however they are a real <br />pain if you want to build e.g. a high performance database: <br />Suppose there are 20 server processes operating on a single huge <br />B-tree in a memory mapped database file. Inserting a node with <br />minimal blocking of concurrent accesses by the other 19 processes <br />in a large B-tree can require around 100 semaphore operations, and <br />this means currently 100 kernel calls :-(. With POSIX.1b's user <br />memory based semaphores, you put all your semaphores in a piece of <br />shared memory and the library accesses them with highly efficient <br />test-and-set machine code. System calls will then only be <br />necessary in the rare case of a blocking P operation. A high <br />performance database programmer's dream and easy to implement! <br />- In POSIX.1b, both memory mapped files and shared memory are done <br />with the mmap() system call. <br />The new functions for IPC are: <br />mmap(), munmap(), shm_open(), shm_close(), shm_unlink(), ftruncate(), <br />sem_init(), sem_destroy(), sem_open(), sem_close(), sem_unlink(), <br />sem_wait(), sem_trywait(), sem_post(), sem_getvalue(), mq_open(), <br />mq_close(), mq_mq_unlink(), mq_send(), mq_receive(), mq_notify(), <br />mq_setattr(), mq_getattr(), mprotect(). <br />Implementation status: POSIX IPC has not yet been implemented <br />(although a part of the basic mechanisms is already available in the <br />existing SysV IPC code). Since Linux 1.3, mmap() is fully implemented. <br />Eric Dumas <<a href="mailto:dumas@freenix.fr>">dumas@freenix.fr></a> has written me that he has done some <br />work on POSIX IPC, however there are no patches available, yet. <br />Memory locking <br />-------------- <br />Four new functions mlock(), munlock(), mlockall() and munlockall() <br />allow to disable paging for either specified memory regions (mlock()) <br />⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -