linux下有对某个数字有同步的函数吗？

eddy

最初由 kj501 发表
既然如此，谁能介绍一下这些函数是如何使用内核的自旋锁机制的？

内核的自旋锁并没有导出到外部来的。

kj501

最初由 eddy 发表
内核的自旋锁并没有导出到外部来的。

同感，linux内核提供的200多个系统调用中并没有直接导出自旋锁的系统调用。应用程序是没有办法直接使用这种机制的。

realtang

信号灯和自旋锁都是内核用来同步内核的数据结构的。
而且自旋锁用在单处理器上会永远的死循环下去，等待使用某个被锁定的数据的进程永远得不到cpu时间。
linux下得pthread库都是效率不高的用户态所实现得posix调用（gcc所实现）,除非你改内核增加信号灯的系统调用。
否则，在用户态下实现某个共享内存中某个数据结构的锁定，自己模拟内核写个信号灯机制吧。

eddy

最初由 realtang 发表
信号灯和自旋锁都是内核用来同步内核的数据结构的。
而且自旋锁用在单处理器上会永远的死循环下去，等待使用某个被锁定的数据的进程永远得不到cpu时间。
linux下得pthread库都是效率不高的用户态所实现得posix调用（gcc所实现）,除非你改内核增加信号灯的系统调用。
否则，在用户态下实现某个共享内存中某个数据结构的锁定，自己模拟内核写个信号灯机制吧。

自旋锁在新的2.6的内核里在单处理器可以不是死循环的，因为2.6的内核是可以抢占的。

至于PTHREAD库，它的实现很多地方都用到了内核导出的系统调用，而且它也不是GCC实现的，它是GLIBC的扩展部分。还有，用户态也不一定效率不高，很多时候在用户态的开销比在核心态要小，进程/线程调度有个叫upcall的方法就是基于这样的思想的。

我觉得用PTHREAD库的互斥锁没什么不好的，毕竟这是比较成熟的东西，各方面都考虑的周到一些。除非在对性能有很高要求的地方，比如说嵌入式系统，可以自己定制，毕竟嵌入式系统的结构要稍简单一些。

kj501

用户态的线程与内核态线程相比减少了从用户态陷入内核态的开销，在不需要调用内核态的功能时，效率应该比内核态要高。

kj501

用户态的线程与内核态线程相比减少了从用户态陷入内核态的开销。在不需要调用内核态的功能时，只有线程之间互相切换的开销，这种线程间切换的开销要比在用户态与内核态之间切换的开销要少得多，自然效率比内核态要高。

realtang

进程切换，调度及创建和销毁都在内核态完成，当然在内核态实现轻量级进程中某个用户态内存区数据的锁定效率高，只要这个数据结构比较的小。
利用进程描述符的内核堆栈区可以很好的完成。

realtang

要知道虽然就是实现这样小的变量同步的话，一个进程首先使用并建立信号灯，而另一个轻量级进程要使用的话，就会被内核挂起，放入可中断的等待状态的进程队列。
通过每隔10毫秒的定时中断服务例程，内核就会在变量被解锁以后立即唤醒第二个轻量级进程，并把它放入可运行进程队列。
试想，这样的事在用户态完成，效率是多么的低。

eddy

最初由 realtang 发表
要知道虽然就是实现这样小的变量同步的话，一个进程首先使用并建立信号灯，而另一个轻量级进程要使用的话，就会被内核挂起，放入可中断的等待状态的进程队列。
通过每隔10毫秒的定时中断服务例程，内核就会在变量被解锁以后立即唤醒第二个轻量级进程，并把它放入可运行进程队列。
试想，这样的事在用户态完成，效率是多么的低。

要实现你所说的，内核要维持一个用于变量同步的数据结构（互斥锁？）的链表，对于拥有大量线程的系统来说，开销并不小的。

对于一个普通的应用，个人认为没有必要牺牲可移植性这么做，有些事情交给用户态完成得了,又不是实时应用。

kj501

最初由 realtang 发表
要知道虽然就是实现这样小的变量同步的话，一个进程首先使用并建立信号灯，而另一个轻量级进程要使用的话，就会被内核挂起，放入可中断的等待状态的进程队列。
通过每隔10毫秒的定时中断服务例程，内核就会在变量被解锁以后立即唤醒第二个轻量级进程，并把它放入可运行进程队列。
试想，这样的事在用户态完成，效率是多么的低。

我觉得你只看到了问题的一个方面：
如果是同一进程的不同线程之间的同步，用户态的线程完全可以在用户态实现自己的同步机制，不需要陷入内核态去使用内核提供的信号灯，这种情况在实际应用中是很多的，效率也是很高的；如果是分别属于不同进程的线程之间的同步，这种情况下就需要进程的同步，自然要使用内核的信号灯。多了从用户态到内核态切换的开销，自然效率就要下降了。