📄 170.htm
字号:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<title>CTerm非常精华下载</title>
</head>
<body bgcolor="#FFFFFF">
<table border="0" width="100%" cellspacing="0" cellpadding="0" height="577">
<tr><td width="32%" rowspan="3" height="123"><img src="DDl_back.jpg" width="300" height="129" alt="DDl_back.jpg"></td><td width="30%" background="DDl_back2.jpg" height="35"><p align="center"><a href="http://202.112.58.200"><font face="黑体"><big><big>Tsinghua</big></big></font></a></td></tr>
<tr>
<td width="68%" background="DDl_back2.jpg" height="44"><big><big><font face="黑体"><p align="center"> 嵌入式系统 (BM: turbolinux jacobw) </font></big></big></td></tr>
<tr>
<td width="68%" height="44" bgcolor="#000000"><font face="黑体"><big><big><p align="center"></big></big><a href="http://cterm.163.net"><img src="banner.gif" width="400" height="60" alt="banner.gif"border="0"></a></font></td>
</tr>
<tr><td width="100%" colspan="2" height="100" align="center" valign="top"><br><p align="center">[<a href="嵌入式系统.htm">回到开始</a>][<a href="143.htm">上一层</a>][<a href="171.htm">下一篇</a>]
<hr><p align="left"><small>发信人: 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:ftp:// <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>
<ttran@cs.UCR.edu> 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 <dumas@freenix.fr> 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>
or for all pages (code, stack, data, shared memory, mapped files, <br>
shared libraries) to which a process has access (mlockall()). This <br>
allows to guarantee that for instance small time-critical daemons stay <br>
in memory which can help to guarantee response time of these <br>
processes. Under Linux, this (like many other real-time related <br>
features) is only allowed for root processes in order to avoid abuse <br>
of this feature by normal users in large time-sharing systems. <br>
Another application of memory locking are cryptographic computer <br>
security programs. Using mlock(), these systems can ensure that an <br>
unencrypted secret key or a password which is temporarily stored in a <br>
small user space array will never get in contact with the swap device, <br>
where under rare circumstances, someone might find the secret bytes <br>
even many months later. For these applications, it would be desirable <br>
if Linux allowed even non-root processes a small number of mlock()ed <br>
pages (e.g. up to four locked pages per non-root process should be <br>
ok). <br>
Implementation status: Linus has now added full POSIX.1b memory <br>
locking support to Linux alpha test kernel version 1.3.43. There exist <br>
also libc support and manual pages. So you won't have to apply the <br>
POSIX.4_locking patch from Ralf Haller <hal@iitb.fhg.de> any more. <br>
Synchronous I/O <br>
--------------- <br>
Databases, e-mail systems, log daemons, etc. require to be sure that <br>
the written piece of data has actually reached the harddisk, because <br>
transaction protocols require that a system crash or power failure <br>
after the write command can not harm the data any more. POSIX.1b <br>
defines the fsync() and O_SYNC mechanisms which Linux 1.2 already has. <br>
In addition, there is a very useful new function fdatasync() which <br>
requires that the data block is flushed to disk, however which does <br>
NOT require that the inode with the latest access/modification time is <br>
also flushed each time. With fdatasync(), the inode has only to be <br>
written in case the file length, file owner, or permission bits have <br>
changed. In database applications with mostly constant file sizes, <br>
where you sometimes require an fsync() after each few written blocks, <br>
but where you don't care about whether the access times in the inodes <br>
on the disc are always 100% up-to-date, fdatasync() could easily <br>
double (!) the performance of your system. <br>
There is also an msync() function for flushing a range of pages from <br>
memory mapped files to the disk. <br>
Implementation status: fsync(), fdatasync(), msync(), and O_SYNC are <br>
already available. O_DSYNC has not yet been implemented. However <br>
fdatasync() in Linux 1.3.55 is currently only an alias for fsync() and <br>
therefore not yet any more efficient than fsync(). <br>
Timers <br>
------ <br>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -