share memory 只有很少的API 非常方便传递资料 难点：Synchronization 同步问题
1.一个共享的内存，can be accessed by all processes，更快更方便 2.但是存在三个问题 3.Threads vs. Processes 5.在linux中,在creat threads时，如果我们不指定共享的内存，那么它同processes差别并不是很大(含义上) 性能比较 在同一天机器上运行时，通常使用pthreads方式， 在不同机器上时，MPI和pthreads可以搭配使用
P：即是Potable Operating System Interface 带有便携式（可移植）操作系统接口的线程
1.指定该线程去执行对应func() 注意：返回的值 是一个pointer 指针，对应 Pthread_join()函数
每一个thread可执行完全不一样的func() 类似于web service ，不断地有用户发送请求，web端每接收一个请求，就创建一个线程来与之对应，web主线程就不再管理新线程
1.mutex主要是这个datatype,实际是一个struct 2.首先需要init 3. init()之后可以被重复使用 4. 该mutex是一个globe varible （所有线程要共享一个lock才能实现互斥，所以是全局变量） 5. 可以创建多个mutex 6. 最终call destroy 重点：找到程序的critical section
实际问题： 两个threads 一个Producer:不断地产生资料 另一个Consumer:接受资料的人 通过share memory 的buffer来实现数据的传递
1.写的时候可能覆盖 2.读的时候不能读到空 确定Bounded-Buffer什么是空什么时候是满 1.确定空 2.确定满 in始终指向已写入数据的下一位，所以当buffer满时，in指向buffer 的开头，值为0 实现区分empty和full
使用buffer状态来作为lock in只会被producer修改 out只会被consumer修改 就不会出现同步的问题
1.是一个变量 可以去call signe 当某一个condition发生时，可以通过signal信号，将其他在sleep的thread 叫醒 2.对应的function call wait(A)； A会被block signal(); 只会wake up 一个线程 broadcast(); 叫醒所有线程 3.细节，会进行释放lock的操作，以便signal进入该线程 4.Condition Variable使用规范 问题：cond 是全局变量吗？ wait(cond,mutex)是使谁等待？（本线程？） 解释：cond是一个全局变量，CV在critic section中运行，对同一个cond，不会出现多个线程调用cond使自己等待，所以，signal（）只会给一个wait解除等待 5.Condition Variable的执行过程 1.action中 上锁 2.指定cond wait 并释放该锁 3.counter中 上锁(获得该锁) 进入该critical section 4.执行critical section， signal cond，直至执行完 5.counter中 解锁释放 6.action 获得该锁 进而执行critical section后续指令 7.解锁，释放 几个问题： 1.什么是mutex以及lock? 2.有什么特性？ 3.在action中，wait语句已经释放了锁，那么如若其他线程在signal A之前调用了action ,这些线程是否能进入critical section，并开始等待，这里的 同步问题 是如何解决的？ 4.wait语句已经将lock释放，在counter释放锁后，action又重新获得锁，再次释放，这里一共释放了三次，却只创建了两次？ 说明mutex 互斥 lock 锁之间存在某种对应关系，这里的mutex是全局变量，均对应一个lock，wait释放后，counter才能进入，counter未释放前，依旧是锁定状态，只有等counter释放，action才能继续，action最后的释放有意义吗？
1.先创建好我们需要的Thread，放在Thread Pools中 2.function pointer 包在一个Task structure中 1.整个pool是一个struct去描述资源 2.存在task queue任务表
