如果全局变量是由寄存器指向的，那么CPU怎么会有那么多寄存器呢？

蚊见蚊爱

进程在Windows中不是调度单位，线程才是调度单位。

全局变量不是寄存器指向的。

woshiwo

进程线程模型对于不同操作系统差别很大。
对于Linux来说，进程和内核线程是一对一，或者说是同一个粒度的，是内核调度的基本单位。用户线程是基于lib库实现的，并不直接接受内核调度。
solaris的LWP和用户线程是一对一，但与Linux不同，可以接受内核调度。

mantiser

这种问题也拿出来问。。

任务，线程，进程。。

在嵌入式系统中，大部分只有任务的概念，一个任务就是一个调度单元。

bebeowulf2006

进程线程模型对于不同操作系统差别很大。
对于Linux来说，进程和内核线程是一对一，或者说是同一个粒度的，是内核调度的基本单位。用户线程是基于lib库实现的，并不直接接受内核调度。

同意，是1：1 还是M：N还是有关系的。

Cocal

原帖由 escapedog 于 2007-8-14 09:27 发表
我一直以为全局变量是被禁止优化的，可是忽然听到有全局变量参与线程现场切换的说法。迷惑ing......

如果说全局变量是由寄存器指向的，那么如果全局变量的数目超过 CPU 的寄存器数目怎么办呢？

你说的优化是全局变量地址优化在通用寄存器里吗？ 那么编译器当然知道CPU有多少个可用寄存器，不够用了就不优化呗，还能怎样？

莫闲云

这个问题是这样的. 为了提高效率(寄存器的访问速度比内存的访问速度要高). 所以在优化后, 有可能某一线程在某一时刻对全局变量修改时不会立即将这个值写入内存, 而是暂放在寄存器中. 之后一些操作如果对全局变量 进行计算时, 是直接对这个寄存器进行操作. 这样运算速度就会被优化. 当时一段操作结束后, 不再对这个全局变量进行操作(比如函数返回时), 代码才会把寄存器真正写入内存当中.

这样会有这么一个问题, 当一个线程修改某一个全局变量时, 可能会把值暂放在某一个寄存器中. 这样在另一个线程 会观察不到这个全局变量发生变化. 可能带个同步上的问题.

另外这种优化并不是说 在同一时刻 对所有的全局变量 暂存的. 不会有那么多寄存器. 只是暂存其中 在当时使用最频繁的几个全局变量.

flw2

原帖由 woshiwo 于 2007-8-14 23:43 发表
进程线程模型对于不同操作系统差别很大。
对于Linux来说，进程和内核线程是一对一，或者说是同一个粒度的，是内核调度的基本单位。用户线程是基于lib库实现的，并不直接接受内核调度。
solaris的LWP和用户线程 ...

http://pauillac.inria.fr/~xleroy/linuxthreads/faq.html


K. Internals of LinuxThreads
K.1: What is the implementation model for LinuxThreads?
LinuxThreads follows the so-called "one-to-one" model: each thread is actually a separate process in the kernel. The kernel scheduler takes care of scheduling the threads, just like it schedules regular processes. The threads are created with the Linux clone() system call, which is a generalization of fork() allowing the new process to share the memory space, file descriptors, and signal handlers of the parent.

Advantages of the "one-to-one" model include:

    * minimal overhead on CPU-intensive multiprocessing (with about one thread per processor);
    * minimal overhead on I/O operations;
    * a simple and robust implementation (the kernel scheduler does most of the hard work for us).

The main disadvantage is more expensive context switches on mutex and condition operations, which must go through the kernel. This is mitigated by the fact that context switches in the Linux kernel are pretty efficient.