多线程编程(pthread).pptVIP

信号量内部有一个计数器，当计数器值大于一的时候，可以访问信号量保护的临界区资源，当信号量为0的时候，就必须等待。 sem_t sem_init sem_post 将信号量计数器加1 sem_wait 将信号量计数器减1 sem_destroy Q1：信号量与互斥锁的关系？ Q2：如何将前面的例子改用信号量实现？ 线程1 pthread_mutex_lock(A) pthread_mutex_lock(B) … 线程2 pthread_mutex_lock(B) pthread_mutex_lock(A) … 生产者和消费者问题（无限大小缓冲区）： 有两个线程，一个线程表示生产者，向缓冲区中添加新生产的物品；另一个线程表示消费者，从缓冲区中取走物品。 Q1：临界区是什么？ Q2：如何同步？ Q1：如果将第30行和第31行交换会有怎样的结果？ Q2：如果将第21行和第22行交换有什么样的结果？ Q1：任何时候，获得了mutex的情况下，去等待semaphore都很有可能会引起死锁，需要注意 Q2：程序不会错，但是因为P操作的顺序的问题，可能会导致多一次的线程切换。影响效率。 如何做一个有限buffer大小的生产者读写者呢？ 读写者问题 问题来源：同时读一个数据不会造成数据混乱，但是当既有读者又有写者，或者有多个写者的时候，数据就会错乱。 Q1：临界区是什么？ Q2：如何同步？ Q：能看懂吗？这样有什么问题？？？ Lightswitch可以很形象的理解为一个教研室的灯，总是第一个来的人开灯，最后一个走的人关灯。于是，我们可以根据这一特点，封装一个lightswitch的类或结构体。这样可以简化我们的代码。可以将这个lightswitch的代码用于读者的同步。写者的代码不用做改变。 Q：还有问题吗？ 前面的同步机制在不断有读者来时，写者可能会一直得不到写的机会，从而产生写者饥饿。 Q：左边两个方法存在什么问题？ 在很多时候为了保证线程不会出现饥饿，使用一个冗余的turnstile可以解决这个问题。 Q1：对于Mutex，操作系统不会保证Mutex是先到先服务，所以，对于mutex完全可能出现饥饿的情况？怎么办？（提示：用turnstile，课后思考） Q2：在很多时候，我们希望写操作能够优先得到执行。我们又应该怎么做呢？有哪些方法可以做？（课后思考） 1.定界加锁（scope lock） 2.线程安全接口（thread-safe interface） 忘了释放锁，返回语句多条，程序抛出异常。怎么办？ class ScopeLock { public: ScopeLock(pthread_mutex_t *mutex):mutex_(mutex){pthread_mutex_lock(mutex_);} ~ScopeLock(){pthread_mutex_unlock(mutex_);} } Q：联想Scope Lock的思想还能用来做什么呢？ 如何避免锁的重入？以前android有个东东，就是因为重复载入一个spinlock，在某个情况下就出现了死锁。。。怎么办？ 1.Volatile 2.False Sharing 3. Large and Small Critical Sections volatile的效果是让编译器不要对这个变量的读写操作做任何优化，每次读的时候都直接去该变量的内存地址中去读，每次写的时候都直接写到该变量的内存地址中去，即不做任何缓存优化。 volatile在C/C++现有标准中即不能保证原子性（Atomicity）也不能保证顺序性（Ordering），所以几乎所有试图用volatile来进行多线程同步的方案都是错的 When?will?changes?of?shared?data?be?visible?to?other?threads?- Pthreads?standard?guarantees?basic?memory?visibility?rules? thread?creation? memory?state?before?calling?pthread_create(…)?is?visible?to?created?thread? mutex?unlocking?(also?combined?with?condition?variables)? memory?state?before?unlocking?a?mutex?is?visible?to?thread?which?locks?same?mutex? thread?termination?(i.e.?entering?state?“terminated”)? memory?state?before?term