为啥不能统统丢掉？

o,sorry,thanks your reminding,maybe my understand has some problems...I must read books again!

I think these are ways to solve problem,that all can solve the common troubles.
if your resource is more than one,you can use semphore,otherwise you will set more mutex...

"有了信号量以后，还要线程间的互斥锁，进程间的文件锁何用？"
sometimes,maybe one program run reading more than writing,so use read-lock can more efficient than other method.

In general I use semphore on IPC,but mutex on thread...

just my understand,hope senior & wise people to comment!

thanks~

存在即合理。毋庸置疑锁的存在。

例如：
1）semaphore只能用在进程上下文中，不能用在中断上下文中。因为可能导致进程休眠，而中断中是没有进程调度的
2）semaphore可能对应多个holder，而锁在同一个时刻顶多只有一个holder。


Linux Kernel Development 2nd 讲了不少semaphore和spin lock的。
------------
第四节
You can draw some interesting conclusions from the sleeping behavior of semaphores:

Because the contending tasks sleep while waiting for the lock to become available, semaphores are well suited to locks that are held for a long time.

Conversely, semaphores are not optimal for locks that are held for very short periods because the overhead of sleeping, maintaining the wait queue, and waking back up can easily outweigh the total lock hold time.

Because a thread of execution sleeps on lock contention, semaphores can be obtained only in process context because interrupt context is not schedulable.

You can (although you may not want to) sleep while holding a semaphore because you will not deadlock when another process acquires the same semaphore. (It will just go to sleep and eventually let you continue.)

You cannot hold a spin lock while you acquire a semaphore, because you might have to sleep while waiting for the semaphore, and you cannot sleep while holding a spin lock.

These facts highlight the uses of semaphores versus spin locks. In most uses of semaphores, there is little choice as to what lock to use. If your code needs to sleep, which is often the case when synchronizing with user-space, semaphores are the sole solution. It is often easier, if not necessary, to use semaphores because they allow you the flexibility of sleeping. When you do have a choice, the decision between semaphore and spin lock should be based on lock hold time. Ideally, all your locks should be held as briefly as possible. With semaphores, however, longer lock hold times are more acceptable. Additionally, unlike spin locks, semaphores do not disable kernel preemption and, consequently, code holding a semaphore can be preempted. This means semaphores do not adversely affect scheduling latency.

------------

------------
第六节

Table 9.6. What to Use: Spin Locks Versus Semaphores
 Requirement                          Recommended Lock
-------------------------------------------------------------------- 
Low overhead locking                   Spin lock is preferred
 
Short lock hold time                   Spin lock is preferred
 
Long lock hold time                    Semaphore is preferred
 
Need to lock from interrupt context    Spin lock is required
 
Need to sleep while holding lock       Semaphore is required
 

虽然都能用来做进程同步和通信,但侧重点还是不一样的,你仔细研究一下他们的异同,应该就能明白了,而且在应用时以能更好的选择该用那个.

semphore belongs to system V
mutex belongs to POSIX

semphore is mainly for synchronism,process run need resource so waiting them release.
mutex is in order to protect itself,prevent other thread from using its resource.

file lock is read/write lock
every processes/threads can read one file when it's read locked,then write lock waiting...
it can be read by more process as the same time,when it has a read-lock

跟个人习惯和应用场合有关吧，
比如一个函数重进入这个函数开始就需要锁定，我们也许会用信号量

如果这个函数中的几行代码需要锁定 我们可能用互斥锁；

最重要是自己的代码看得清晰吧。

这段论述很深刻。

mutex是直接用spin lock实现，semaphore和spin lock的区别也基本是semaphore和mutex的区别:
二值semaphore和mutex的语义功能确实一致。semaphore通用性强，正如没有免费的午餐一样，在专用性上就不如mutex，即在高并发访问执行时间很短的临界区代码时，mutex在性能上的优势要远远高于二值semaphore，原因：首先，semaphore可能有thread context切换，虽然thread context开销远低于process context切换，但是对于高并发多线程应用来说，这是一个瓶颈；其次，semaphore本身实现也是基于spin lock，和mutex比较起来，多加了对于semaphore值的控制，意味着实现的复杂性，二值信号量也不例外。

file & recording locking和semaphore虽然都可用做进程间同步，但是它们的应用范围基本没什么交集，更谈不替换。advisory & mandatory record locking发展主要基于多用户数据库访问的推动，用来同步进程访问文件系统。System V和Posix的semaphore在创建时可能会依赖文件系统，但是使用都是基于内存访问，和文件系统没关系

三者功能有类似，都有最擅长的一面，但是没有任何一个可以完全替代另一个

目前linux pthread的同步原语由系统调用futex提供,futex基于spinlock实现。spinlock出现前，用户态mutex同样基于另外一种核心态同步原语实现，不影响用户态mutex和semaphore高层行为的讨论吧
http://www.kernel.org/doc/man-pages/online/pages/man7/pthreads.7.html
http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/kernel/futex.c?v=2.6.11.8
http://www.cs.purdue.edu/homes/cs354/LectureNotes/Fall2000/9/

呵呵，我也没真正研究过内核，这些都是四处找到的只言片语。不过对于使用Posix thread和Posix & System Semaphore应该不需要了解太多内核的实现。

线程和进程控制以及同步确实是很复杂和有难度的内容, 推荐一本书,楼主可以看一下: , 这里面有专门的章节来介绍线程进程控制和同步等.

应该是各有千秋吧。
互斥量：多个线程企图在同一个时刻修改相同的变量，用互斥量 。  
        优点：使线程间很好的合作，避免对于变量、函数以及资源的访问冲突。
        缺点：它使程序运行变慢，程序效率低下。
信号量：信号量是一个变量，它可以被系统中的任何进程所访问。
        进程间可以使用这个变量来协调对于共享内存和其他资源的访问。

条件对象是进程中的全局变量，而信号量是系统中的全局变量。

信号量的使用比线程复杂的多，进程可以接受任何种类的信号量。线程也是。
条件变量：


线程间的互斥锁：线程间。
进程间的文件锁：进程间。
进程间的通信：（3种）
1.文件。
2.命名管道。
3.共享内存。（为解决访问文件冲突，其中提供了一个更加灵活的机制来合作：信号量）

还有消息队列

不是很明白，照书上说的，呵呵