交互设计在未来很有前途，不要再说是做界面的了。
分类：
2009-06-21 11:37:46
1. 进程 线程
下面介绍一下线程的概念，线程（thread）技术早在60年代就被提出，但真正应用多
线程到操作系统中去，是在80年代中期，solaris是这方面的佼佼者。传统的Unix也支
持线程的概念，但是在一个进程（process）中只允许有一个线程，这样多线程就意味
着多进程。现在，多线程技术已经被许多操作系统所支持，包括Windows/NT，当然，也
包括Linux。但是线程的实现在类unix下并不相同，基本上分为内核支持方式和用户空
间支持方式，如果线程的上下文切换是在内核中实现的，我们就称之为内核方式实现，
但如果线程的切换是在用户空间进行的我们就称之为用户方式实现，内核并不知情，当
然还有两种方式的混合方式，用户空间中的多个线程在内核空间有相应的内核线程与之
对应（通常我们称此内核线程为LWP-轻级进程）。
http://www.nsfocus.net/index.php?act=sec_self&do=view&doc_id=711
Operating system organization
传统的UNIX支持现成概念--每一个进程包含一个单线程，所以用多进程就 是使用多线程。但是一个进程还有一个地址空间，创建一个新进程意味着需要 创建一个新的地址空间。
因此，创建一个进程是昂贵的，而在一个已经存在的进程内部创建线程是 廉价的。创建一个线程的时间比创建一个进程的时间要少成千倍，部分是因为 在线程间切换不涉及地址空间的切换。
在进程内部的线程间通信很简单，因为线程们共享所有的东西--特别是地址空间。所以被一个线程生成的数据可以立刻提供给其他线程。
支持多线程的接口（界面）是通过一个函数库libthread实现的。多线程通过把内核级资源和用户级资源独立开来提供了更多的灵活性。
多线程的标准
多线程编程的历史可以回溯到二十世纪60年代。在UNIX操作系统中的发展是从 80年代中期开始的。也许是令人吃惊的，关于支持多线程有很好的协议，但是今 天我们仍然可以看到不同的多线程开发包，他们拥有不同的接口。
但是，某几年里一个叫做POSIX
可重入性是指函数可以被多个任务进程调用。在多任务操作系统中，函数是否具有可重入性是非常重要的，因为这是多个进程可以共用此函数的必要条件。另外，编译器是否提供可重入函数库，与它所服务的操作系统有关，只有操作系统是多任务时，编译器才有可能提供可重入函数库。如DOS下BC和MSC等就不具备可重入函数库，因为DOS是单用户单任务操作系统。
编写C/C++语言的可重入函数时，不应使用static局部变量，否则必须经过特殊处理，才能使函数具有可重入性。
In UNIX, developers implement threads by using the POSIX pthread functions. In Win32, developers can implement UNIX threading by using the Win32 API thread management functions. The functionality and operation of threads in UNIX and Win32 is very similar; however, the function calls and syntax are very different.
Msdn 《UNIX Code Migration Guide》
关于线程使用的一些问题
http://www-128.ibm.com/developerworks/cn/linux/thread/posix_thread1/
2. 共享内存
Shared memory permits two or more threads or processes to share a region of
memory. It is generally considered the most performant method of IPC because
data is not copied as part of the communication process. Instead, the same physical
area of memory is accessed by both the client and the server.
Windows does not support the standard System V interprocess communications
mechanisms for shared memory (the shm*() APIs). It does, however, support
memory-mapped files and memory-mapped page files, which you can use as
an alternative to the shm*() APIs.
“Appendix 9.1: Shared Memory” presents an example of how to port a simple UNIX
application based on System V IPC to Windows based on memory-mapped page files.
〈unix application migration guide〉p322
3. 进程调度
This section looks at how you can change the scheduling priority of a thread
in UNIX and Win32.
Ideally, you want to map Win32 priority classes to UNIX scheduling policies, and
Win32 thread priority levels to UNIX priority levels. Unfortunately, it isn’t this simple.
The priority level of a Win32 thread is determined by both the priority class of its
process and its priority level. The priority class and priority level are combined to
form the base priority of each thread.
Every thread in Windows has a base priority level determined by the thread’s
priority value and the priority class of its owning process. The operating system
uses the base priority level of all executable threads to determine which thread
gets the next slice of CPU time. Threads are scheduled in a round-robin fashion at
each priority level, and only when there are no executable threads at a higher level
will scheduling of threads at a lower level take place.
UNIX offers both round-robin and FIFO scheduling algorithms, whereas Windows
uses only round-robin. This does not mean that Windows is less flexible; it simply
means that any fine tuning that was performed on thread scheduling in UNIX has to
be implemented differently when using Windows.
Table 9.7 shows the base priority levels for combinations of priority class and priority
value.
〈unix application migration guide〉p309-310
