用户态进程中多线程并发的疑问？
本帖最后由 镇水铁牛 于 2015-02-08 19:30 编辑场景：glibc的线程库，一个进程内起多个线程，谈谈我的理解和看法？
该进程有独立的地址空间，可以被内核调度，但它内部的多线程是无法真正意义上的并发执行，即无法同一时刻在多个cpu上并行，这些线程顶多是在进程的时间片内进行调度执行，其实内核根本不感知这些，毕竟这些线程只是共享了该进程的一些数据结构而已，理解是否正确？
实际场景：进程A中有8个线程，线程中均执行while (true) { i ++}死循环，cpu的使用率大于100%，这个值是进行进程时间片相关的virtual runtime后加权算出来的吧？ 楼主请教一个问题，进程地址空间独立，这个我明白，我是想问，为啥多线程不能在不同的CPU上并发执行，是因为不同的CPU不能共享地址空间吗？
如果多CPU不能共享一个地址空间，我想问一下，CPU 的多核处理器是否能够共享一个地址空间？
多线程是否能够在多核上并发运行，如果多核可以，多CPU不可以，那么多核与多CPU的差别在哪里? 一个进程内的线程无法真正意义上的并行执行，这个是错误的吧，我认为线程其实就是轻量级的进程，空间也是共享+COW的，所以完全是可以并行的，不然你写代码的时候，进程内的多线程岂不是就不需要加锁了？
至于一些内核资源，临界区，我觉得这个是无法并行的
线程分为用户态线程和内核态线程，它们的对应关系有三种模型 ht:mrgreen:tp://blog.csdn.net/baidu_24256693/article/details/43446763 回复 2# zsszss0000
楼主请教一个问题，进程地址空间独立，这个我明白，我是想问，为啥多线程不能在不同的CPU上并发执行，是因为不同的CPU不能共享地址空间吗？
如果多CPU不能共享一个地址空间，我想问一下，CPU 的多核处理器是否能够共享一个地址空间？
多线程是否能够在多核上并发运行，如果多核可以，多CPU不可以，那么多核与多CPU的差别在哪里?
[回复]首先改正下我的说法，我说的多cpu不是所谓的多路概念，就是普通的SMP。
多核共享地址空间，用户态线程理论上是可以并发的，我的疑问是有没有必要进行真正意义上的并发，这样其实是提高了用户态线程被调度的机率，不过也可以理解，内核本来就是为用户提供服务的。
回复 3# weishuo1999
一个进程内的线程无法真正意义上的并行执行，这个是错误的吧，我认为线程其实就是轻量级的进程，空间也是共享+COW的，所以完全是可以并行的，不然你写代码的时候，进程内的多线程岂不是就不需要加锁了？
即使没有真正意义上的并发，访问某些共享资源也需要锁保护吧，例如：thread_a刚正准备删除链表中某元素时被调度，thread_b刚好被调度去访问该链表。风险就来了。
回复 4# lxy572535121
用户级线程是一种"多对一"的线程映射。听起来很有道理，但是好像还真不是那样的哦，下面的测试可以证明。
我做的测试如下：一个进程中起4个线程，每个线程就是while (true) { i++ ;}，实际上上该进程消耗的cpu资源为400%，top中4个核心的cpu每个核心的使用率都是100%。
镇水铁牛 发表于 2015-02-09 23:07 static/image/common/back.gif
回复 4# lxy572535121
用户级线程是一种"多对一"的线程映射。听起来很有道理，但是好像还真不是那样的哦 ...
你说的是对的，我在ubuntu12.04上测试过
但博客中说的是有这三中模型，而显然你的系统用的是第二种模型即用户级线程与内核级线程一对一的情况，而不是多对一的模型 回复 8# lxy572535121
确实是那样的。
glibc在linux上就是一对一啊 solaris才有多对一的
glibc的线程直接对应内核的轻量级进程 一个进程的两个线程可以同时在两个cpu上*并行*执行
页:
[1]