linux semaphore，linux基础知识点

大家好，关于linux semaphore很多朋友都还不太明白，今天小编就来为大家分享关于linux基础知识点的知识，希望对各位有所帮助！

linux线程查询指令linux线程查询

怎么在linux系统下查看网卡状态信息？

方法一:

ethtooleth0采用此命令可以查看到网卡相关的技术指标。

(不一定所有网卡都支持此命令)

ethtool-ieth1加上-i参数查看网卡驱动。

可以尝试其它参数查看网卡相关技术参数。

方法二:

也可以通过dmesg|grepeth0等看到网卡名字(厂家)等信息。

通过查看/etc/sysconfig/network-scripts/ifcfg-eth0可以看到当前的网卡配置包括IP、网关地址等信息。

当然也可以通过ifconfig命令查看。

Linux是一套免费使用和自由传播的类Unix操作系统，是一个基于POSIX和UNIX的多用户、多任务、支持多线程和多CPU的操作系统。它能运行主要的UNIX工具软件、应用程序和网络协议。它支持32位和64位硬件。Linux继承了Unix以网络为核心的设计思想，是一个性能稳定的多用户网络操作系统。Linux操作系统诞生于1991年10月5日（这是第一次正式向外公布时间）。Linux存在着许多不同的Linux版本，但它们都使用了Linux内核。Linux可安装在各种计算机硬件设备中，比如手机、平板电脑、路由器、视频游戏控制台、台式计算机、大型机和超级计算机。严格来讲，Linux这个词本身只表示Linux内核，但实际上人们已经习惯了用Linux来形容整个基于Linux内核，并且使用GNU工程各种工具和数据库的操作系统。

linux查看活跃线程命令？

可以执行ps-ef进行查看

Linux多线程通信？

PIPE和FIFO用来实现进程间相互发送非常短小的、频率很高的消息；

这两种方式通常适用于两个进程间的通信。

共享内存用来实现进程间共享的、非常庞大的、读写操作频率很高的数据（配合信号量使用）；

这种方式通常适用于多进程间通信。

其他考虑用socket。这里的“其他情况”，其实是今天主要会碰到的情况：

分布式开发。

在多进程、多线程、多模块所构成的今天最常见的分布式系统开发中，

socket是第一选择

。消息队列，现在建议不要使用了----因为找不到使用它们的理由。在实际中，我个人感觉，PIPE和FIFO可以偶尔使用下，共享内存都用的不多了。在效率上说，socket有包装数据和解包数据的过程，所以理论上来说socket是没有PIPE/FIFO快，不过现在计算机上真心不计较这么一点点速度损失的。你费劲纠结半天，不如我把socket设计好了，多插一块CPU来得更划算。另外，进程间通信的数据一般来说我们都会存入数据库的，这样万一某个进程突然死掉或者整个服务器死了，也不至于丢失重要数据、便于回滚到之前的状态。从这个角度考虑，适用共享内存的情况也更少了，所以socket使用得更多。再多说一点关于共享内存的：共享内存的效率确实高，但它的重点在“共享”二字上。如果的确有好些进程共享一大块数据（如果把每个进程都看做是类的对象的话，那么共享数据就是这个类的static数据成员），那么共享内存就是一个不二的选择了。但是在面向对象的今天，我们更多的时候是多线程+锁+线程间共享数据。因此共享进程在今天使用的也越来越少了。不过，在面对一些极度追求效率的需求时，共享内存就会成为唯一的选择，比如高频交易系统。除此以外，一般是不需要特意使用共享内存的。另外，

PIPE和共享内存是不能跨LAN的

（FIFO可以但FIFO只能用于两个进程通信）

。

如果你的分布式系统随着需求的增加而越来越大所以你想把不同的模块放在不同机器上而你之前开发的时候用了PIPE或者共享内存，那么你将不得不对代码进行大幅修改......同时，即使FIFO可以跨越LAN，其代码的可读性、易操作性和可移植性、适应性也远没有socket大。这也就是为什么一开始说socket是第一选择的原因。最后还有个信号简单说一下。

请注意，是信号，不是信号量。

信号量是用于同步线程间的对象的使用的（建议题主看我的答案，自认为比较通俗易懂：

semaphore和mutex的区别？-Linux-知乎

）。信号也是进程间通信的一种方式。比如在Linux系统下，一个进程正在执行时，你用键盘按Ctrl+c，就是给这个进程发送了一个信号。进程在捕捉到这个信号后会做相应的动作。虽然信号是可以自定义的，但这并不能改变信号的局限性：

不能跨LAN、信息量极其有限

。在现代的分布式系统中，通常都是

消息驱动：

即进程受到某个消息后，通过对消息的内容的分析然后做相应的动作。如果你把你的分布式系统设置成信号驱动的，这就表示你收到一个信号就要做一个动作而一个信号的本质其实就是一个数字而已。这样系统稍微大一点的话，系统将变得异常难以维护；甚至在很多时候，信号驱动是无法满足我们的需求的。因此现在我们一般也不用信号了。因此，请记住：

除非你有非常有说服力的理由，否则请用socket。

顺便给你推荐个基于socket的轻量级的消息库：ZeroMQ。

linux下，如何查看工控机的串口被哪个线程占用，能否使该线程强制释放串口？

在串口的驱动程序注册的open函数里加入这样一句话：printk("process%dhasopenttyn",current->pid);可以判断出来哪个进程打开了串口设备，或者是否有进程打开串口current->pid的值表示进程号！

spinlock 和 Semaphore信号量的区别

Mutex是一把钥匙，一个人拿了就可进入一个房间，出来的时候把钥匙交给队列的第一个。一般的用法是用于串行化对critical section代码的访问，保证这段代码不会被并行的运行。

Semaphore是一件可以容纳N人的房间，如果人不满就可以进去，如果人满了，就要等待有人出来。对于N=1的情况，称为binary semaphore。一般的用法是，用于限制对于某一资源的同时访问。

Binary semaphore与Mutex的差异：

在有的系统中Binary semaphore与Mutex是没有差异的。在有的系统上，主要的差异是mutex一定要由获得锁的进程来释放。而semaphore可以由其它进程释放（这时的semaphore实际就是个原子的变量，大家可以加或减），因此semaphore可以用于进程间同步。Semaphore的同步功能是所有系统都支持的，而Mutex能否由其他进程释放则未定，因此建议mutex只用于保护critical section。而semaphore则用于保护某变量，或者同步。

另一个概念是spin lock，这是一个内核态概念。spin lock与semaphore的主要区别是spin lock是busy waiting，而semaphore是sleep。对于可以sleep的进程来说，busy waiting当然没有意义。对于单CPU的系统，busy waiting当然更没意义（没有CPU可以释放锁）。因此，只有多CPU的内核态非进程空间，才会用到spin lock。Linux kernel的spin lock在非SMP的情况下，只是关irq，没有别的操作，用于确保该段程序的运行不会被打断。其实也就是类似mutex的作用，串行化对critical section的访问。但是mutex不能保护中断的打断，也不能在中断处理程序中被调用。而spin lock也一般没有必要用于可以sleep的进程空间。

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

内核同步措施

为了避免并发，防止竞争。内核提供了一组同步方法来提供对共享数据的保护。我们的重点不是介绍这些方法的详细用法，而是强调为什么使用这些方法和它们之间的差别。

Linux使用的同步机制可以说从2.0到2.6以来不断发展完善。从最初的原子操作，到后来的信号量，从大内核锁到今天的自旋锁。这些同步机制的发展伴随 Linux从单处理器到对称多处理器的过度；伴随着从非抢占内核到抢占内核的过度。锁机制越来越有效，也越来越复杂。

目前来说内核中原子操作多用来做计数使用，其它情况最常用的是两种锁以及它们的变种:一个是自旋锁，另一个是信号量。我们下面就来着重介绍一下这两种锁机制。

自旋锁

自旋锁是专为防止多处理器并发而引入的一种锁，它在内核中大量应用于中断处理等部分(对于单处理器来说，防止中断处理中的并发可简单采用关闭中断的方式，不需要自旋锁)。

自旋锁最多只能被一个内核任务持有，如果一个内核任务试图请求一个已被争用(已经被持有)的自旋锁，那么这个任务就会一直进行忙循环——旋转——等待锁重新可用。要是锁未被争用，请求它的内核任务便能立刻得到它并且继续进行。自旋锁可以在任何时刻防止多于一个的内核任务同时进入临界区，因此这种锁可有效地避免多处理器上并发运行的内核任务竞争共享资源。

事实上，自旋锁的初衷就是：在短期间内进行轻量级的锁定。一个被争用的自旋锁使得请求它的线程在等待锁重新可用的期间进行自旋(特别浪费处理器时间)，所以自旋锁不应该被持有时间过长。如果需要长时间锁定的话,最好使用信号量。

自旋锁的基本形式如下：

spin_lock(&mr_lock);

//临界区

spin_unlock(&mr_lock);

因为自旋锁在同一时刻只能被最多一个内核任务持有，所以一个时刻只有一个线程允许存在于临界区中。这点很好地满足了对称多处理机器需要的锁定服务。在单处理器上，自旋锁仅仅当作一个设置内核抢占的开关。如果内核抢占也不存在，那么自旋锁会在编译时被完全剔除出内核。

简单的说，自旋锁在内核中主要用来防止多处理器中并发访问临界区，防止内核抢占造成的竞争。另外自旋锁不允许任务睡眠(持有自旋锁的任务睡眠会造成自死锁——因为睡眠有可能造成持有锁的内核任务被重新调度，而再次申请自己已持有的锁)，它能够在中断上下文中使用。

死锁：假设有一个或多个内核任务和一个或多个资源，每个内核都在等待其中的一个资源，但所有的资源都已经被占用了。这便会发生所有内核任务都在相互等待，但它们永远不会释放已经占有的资源，于是任何内核任务都无法获得所需要的资源，无法继续运行，这便意味着死锁发生了。自死琐是说自己占有了某个资源，然后自己又申请自己已占有的资源，显然不可能再获得该资源，因此就自缚手脚了。

信号量

Linux中的信号量是一种睡眠锁。如果有一个任务试图获得一个已被持有的信号量时，信号量会将其推入等待队列，然后让其睡眠。这时处理器获得自由去执行其它代码。当持有信号量的进程将信号量释放后，在等待队列中的一个任务将被唤醒，从而便可以获得这个信号量。

信号量的睡眠特性，使得信号量适用于锁会被长时间持有的情况；只能在进程上下文中使用，因为中断上下文中是不能被调度的；另外当代码持有信号量时，不可以再持有自旋锁。

信号量基本使用形式为：

static DECLARE_MUTEX(mr_sem);//声明互斥信号量

if(down_interruptible(&mr_sem))

//可被中断的睡眠，当信号来到，睡眠的任务被唤醒

//临界区

up(&mr_sem);

信号量和自旋锁区别

虽然听起来两者之间的使用条件复杂，其实在实际使用中信号量和自旋锁并不易混淆。注意以下原则:

如果代码需要睡眠——这往往是发生在和用户空间同步时——使用信号量是唯一的选择。由于不受睡眠的限制，使用信号量通常来说更加简单一些。如果需要在自旋锁和信号量中作选择，应该取决于锁被持有的时间长短。理想情况是所有的锁都应该尽可能短的被持有，但是如果锁的持有时间较长的话，使用信号量是更好的选择。另外，信号量不同于自旋锁，它不会关闭内核抢占，所以持有信号量的代码可以被抢占。这意味者信号量不会对影响调度反应时间带来负面影响。

自旋锁对信号量

需求建议的加锁方法

低开销加锁优先使用自旋锁

短期锁定优先使用自旋锁

长期加锁优先使用信号量

中断上下文中加锁使用自旋锁

持有锁是需要睡眠、调度使用信号量

Linux 中编程的 semaphore结构体在哪个头文件中

down接口用于请求一个信号量。此函数的调用将会到致调用线程的睡眠，直到获取到信号。同时，该函数的调用不允许中断。

在此函数中首先进行信号量资源数的查看，如果信号量数据(count)不为0，则把其减1，并返回，调用成功；否则调用__down进行等待，调用者进行睡眠。

up接口用于唤醒处于等待的线程，对于某些不能获取信号量的线程，如果不强制唤醒，那么也许会造此线程的死掉，所以，才有up接口。