T9的空间

You will never walk alone!

  C++博客 :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理 ::
  69 随笔 :: 0 文章 :: 28 评论 :: 0 Trackbacks
第一章
印象:
硬件PCI/ISA的架构
North Bridge相当于人的心脏,连接所有高速设备,CPU ->大脑
南桥芯片则负责低速设备连接
  
SMP
 
中间层 是解决很多问题的大方向
Any problem in computer science can be resolved by another layer of indirection
 
CPU密集型 IO密集型
这两种类型的Process,理论上优先级高的,也就是说最应该先得到CPU的是IO密集型
通俗的理解应该是IO密集型做完事情花的CPU时间最少,然后就会等待IO设备的反应,这样可以让设备性能最大化
 
Memory
分段分页 MMU
 

线程安全和线程模型
 

其中线程安全有两件事情要注意
Semaphore
Mutex
上面这两个可以做成全局的,并不一定是By Process的,例如POSIX pthread在
对Mutex做attr设定的时候就可以指定为 shared process
也就是说一个Process可以加锁,另外一个可以释放他。
另外这种Mutex必须处在共享内存中,否则没办法访问。有亲缘关系的Process可以通过mmap一个匿名映射做到
anyway有很多方式了。
 
Critical Section
这个是Inter Process的东西。
 
关于线程互斥的lock的问题
RW lock就是对普通lock记录两个状态来供read or write操作选择
 
属于线程本身的东西 TLS/Stack/Register
 
有时候编译器会为了做优化
内存和寄存器的数据会出现不sync的状态。
即使你用lock来做保护,也不一定能OK。然后volatile就出现了。 
 
volatile最主要的作用就是thread内保证编译器不要做优化,防止这种不sync带来的问题。
一般是这样例如x变量,thread_1读到x变量放到了寄存器中,因为可能马上会再访问它,那么对x进行操作后就不会写回内存
这样即使你加了lock,这个时候lock也被释放掉了(操作完成),但是结果未能Sync,那么thread 2来访问x的时候,在内存
中拿到的值就变成dirty状态了。
 
另外一种过度优化就是CPU做的优化,有些上下语义无关的指令,CPU有可能会调整运行顺序。
书中有个经典样例
一段 Singleton pattern的double-check的代码
volatile T* pInst = NULL;
T* getInstance()
{
if (pInst == NULL)
{
lock();
if (pInst == NULL)
pInst = new T();
unlock();
}
return pInst;
}

 
这里有两点
第一,double-check 也就是双if能避免过多的无用的get lock,降低消耗
对临界区需要做保护的资源,可以提前去取状态,如果符合自己的预期,而且短时间不会有变化,那么就不用去拿锁了
不知道为啥我想到了unlikely,但仔细想一下,功能完全不同。
 
第二点也就是要说的CPU的过度优化
这里已经是声明volatile了,所以没有寄存器和内存不sync的问题
但是由于这里new需要先 malloc出空间,然后call T的constructor。
所以有可能会发生这种情况,malloc出空间后,把地址付给pInst,然后去做初始化;
这样就有可能另外一个线程取得的object是没有被完全初始化好的,是否会出问题depend on T的具体实现了。
许多CPU提供了barrier指令用来解决上面提到的问题。
 
线程模型
这个东西,我看了下,开始没看明白,这边书这个东西没讲清楚,后来去网上找了些资料。用户线程和内核线程的对应关系取决于调度单位。
也就是说内核把什么东西当做一个调度单位
 
拿Linux来说吧,Process是线程集和资源集
 
调度的时候,那些共享资源的Task(thread)之间的调度肯定比那些跨Process不共享资源的thread做context switch消耗的资源
多得多。
 
基于调度消耗之类的考量
模型分为下面几种
 
一对一,也就是说 user space create出来的线程就是和kernel的调度单位相同,称一一对应
 
一对多,应该是这样一种情况,kernel看到的是Process,userspace自己实现出来自己的thread,这个thread,kernel是不知道的
调度的时候kernel负责分批CPU给他能看到的Process,上层userspace自己来调度分配这个Process获得的CPU time给这个process中的
各个线程。
这样的分配就可以保证在一定的时间内只需要做一些register和stack的切换,不会有memory等等的switch。
坏处是上面的thread只要一个被suspend,那么这个Process里面的其他thread也就被suspend住了,一般上层调度程序
不会假定其他的thread能run,所以一般会是kernel把CPU time给其他process
 
多对多,就是一种混合的情况了,我想到了Android,但是Android是一对一模型,dalvik会保证Java thread对应下面一个
native thread,想说的是,这种虚拟机架构可以做成多对多的样子,一个native thread run一个JVM,JVM开出来很多Java Thread,
JVM负责调度这些Java Thread,Native负责调度JVM所在的Thread。
不知道我有没有讲错。

posted on 2013-10-18 19:42 Torres 阅读(222) 评论(0)  编辑 收藏 引用 所属分类: Compile & Link

只有注册用户登录后才能发表评论。
【推荐】超50万行VC++源码: 大型组态工控、电力仿真CAD与GIS源码库
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理