alarm()原型：
#include <unistd.h>
unsigned int alarm(unsigned int seconds)
这个函数在使用上很简单，第一次调用这个函数的时候是设置定时器的初值，下一次调用是重新设置这个值，并会返回上一次定时的剩余时间。
setitimer()原型：
#include <sys/time.h>
int setitimer(int which, const struct itimerval *value,struct itimerval *ovalue)
这个函数使用起来稍微有点说法，首先是第一个参数which的值，这个参数设置timer的计时策略，which有三种状态分别是：
ITIMER_REAL：使用系统时间来计数，时间为0时发出SIGALRM信号，这种定时能够得到一个精准的定时，当然这个定时是相对的，因为到了微秒级别我们的处理器本身就不够精确。
ITIMER_VIRTUAL：使用进程时间也就是进程分配到的时间片的时间来计数，时间为0是发出SIGVTALRM信号，这种定时显然不够准确，因为系统给进程分配时间片不由我们控制。
ITIMER_PROF：上面两种情况都能够触发
第二个参数参数value涉及到两个结构体：
struct itimerval {
struct timeval it_interval /* next value */
struct timeval it_value /* current value */
}
struct timeval {
long tv_sec /* seconds */
long tv_usec /* microseconds */
}
在结构体itimerval中it_value是定时器当前的值，it_interval是当it_value的为0后重新填充的值。而timeval结构体中的两个变量就简单了一个是秒一个是微秒。
上面是这两个定时函数的说明，这个函数使用本不是很难，可以说是很简单，但是碰到具体的应用的时候可能就遇到问题了，在多进程编程中使用一般不会碰到什么问题，这里说的这些问题主要体现在多线程编程中。比如下面这个程序：
#include <pthread.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/time.h>
void sig_handler(int signo)
{
alarm(2)
printf("alarm signal\n")
}
void *pthread_func()
{
alarm(2)
while(1)
{
pause()
}
}
int main(int argc, char **argv)
{
pthread_t tid
int retval
signal(SIGALRM, sig_handler)
if((retval = pthread_create(&tid, NULL, pthread_func, NULL)) <0)
{
perror("pthread_create")
exit(-1)
}
while(1)
{
printf("main thread\n")
sleep(10)
}
return 0
}
这个程序的理想结果是：
main thread
alarm signal
alarm signal
alarm signal
alarm signal
alarm signal
main thread
可事实上并不是这样的，它的结果是：
main pthread
alarm signal
main pthread
alarm signal
main pthread
每个进程的用户地址空间都是独立的，一般而言是不能互相访问的，但内核空间是每个进程都共享的，所以进程之间要通信必须通过内核。
上面命令行里的「|」竖线就是一个管道，它的功能是将前一个命令（ps auxf）的输出，作为后一个命令（grep mysql）的输入，从这功能描述，可以看出管道传输数据是单向的，如果想相互通信，我们需要创建两个管道才行。
同时，我们得知上面这种管道是没有名字，所以「|」表示的管道称为匿名管道，用完了就销毁。
管道还有另外一个类型是命名管道，也被叫做 FIFO，因为数据是先进先出的传输方式。
在使用命名管道前，先需要通过 mkfifo 命令来创建，并且指定管道名字
myPipe 就是这个管道的名称，基于 Linux 一切皆文件的理念，所以管道也是以文件的方式存在，我们可以用 ls 看一下，这个文件的类型是 p，也就是 pipe（管道） 的意思：
你 *** 作了后，你会发现命令执行后就停在这了，这是因为管道里的内容没有被读取，只有当管道里的数据被读完后，命令才可以正常退出。
于是，我们执行另外一个命令来读取这个管道里的数据：
可以看到，管道里的内容被读取出来了，并打印在了终端上，另外一方面，echo 那个命令也正常退出了。
我们可以看出，管道这种通信方式效率低，不适合进程间频繁地交换数据。当然，它的好处，自然就是简单，同时也我们很容易得知管道里的数据已经被另一个进程读取了。
前面说到管道的通信方式是效率低的，因此管道不适合进程间频繁地交换数据。
对于这个问题，消息队列的通信模式就可以解决。比如，A 进程要给 B 进程发送消息，A 进程把数据放在对应的消息队列后就可以正常返回了，B 进程需要的时候再去读取数据就可以了。同理，B 进程要给 A 进程发送消息也是如此。
再来，消息队列是保存在内核中的消息链表，在发送数据时，会分成一个一个独立的数据单元，也就是消息体（数据块），消息体是用户自定义的数据类型，消息的发送方和接收方要约定好消息体的数据类型，所以每个消息体都是固定大小的存储块，不像管道是无格式的字节流数据。如果进程从消息队列中读取了消息体，内核就会把这个消息体删除。
消息队列生命周期随内核，如果没有释放消息队列或者没有关闭 *** 作系统，消息队列会一直存在，而前面提到的匿名管道的生命周期，是随进程的创建而建立，随进程的结束而销毁。
消息这种模型，两个进程之间的通信就像平时发邮件一样，你来一封，我回一封，可以频繁沟通了。
但邮件的通信方式存在不足的地方有两点，一是通信不及时，二是附件也有大小限制，这同样也是消息队列通信不足的点。
消息队列不适合比较大数据的传输，因为在内核中每个消息体都有一个最大长度的限制，同时所有队列所包含的全部消息体的总长度也是有上限。在 Linux 内核中，会有两个宏定义 MSGMAX 和 MSGMNB，它们以字节为单位，分别定义了一条消息的最大长度和一个队列的最大长度。
消息队列通信过程中，存在用户态与内核态之间的数据拷贝开销，因为进程写入数据到内核中的消息队列时，会发生从用户态拷贝数据到内核态的过程，同理另一进程读取内核中的消息数据时，会发生从内核态拷贝数据到用户态的过程。
消息队列的读取和写入的过程，都会有发生用户态与内核态之间的消息拷贝过程。那共享内存的方式，就很好的解决了这一问题。
现代 *** 作系统，对于内存管理，采用的是虚拟内存技术，也就是每个进程都有自己独立的虚拟内存空间，不同进程的虚拟内存映射到不同的物理内存中。所以，即使进程 A 和 进程 B 的虚拟地址是一样的，其实访问的是不同的物理内存地址，对于数据的增删查改互不影响。
用了共享内存通信方式，带来新的问题，那就是如果多个进程同时修改同一个共享内存，很有可能就冲突了。例如两个进程都同时写一个地址，那先写的那个进程会发现内容被别人覆盖了。
为了防止多进程竞争共享资源，而造成的数据错乱，所以需要保护机制，使得共享的资源，在任意时刻只能被一个进程访问。正好，信号量就实现了这一保护机制。
信号量其实是一个整型的计数器，主要用于实现进程间的互斥与同步，而不是用于缓存进程间通信的数据。
信号量表示资源的数量，控制信号量的方式有两种原子 *** 作：
P *** 作是用在进入共享资源之前，V *** 作是用在离开共享资源之后，这两个 *** 作是必须成对出现的。
接下来，举个例子，如果要使得两个进程互斥访问共享内存，我们可以初始化信号量为 1。
具体的过程如下：
可以发现，信号初始化为 1，就代表着是互斥信号量，它可以保证共享内存在任何时刻只有一个进程在访问，这就很好的保护了共享内存。
另外，在多进程里，每个进程并不一定是顺序执行的，它们基本是以各自独立的、不可预知的速度向前推进，但有时候我们又希望多个进程能密切合作，以实现一个共同的任务。
例如，进程 A 是负责生产数据，而进程 B 是负责读取数据，这两个进程是相互合作、相互依赖的，进程 A 必须先生产了数据，进程 B 才能读取到数据，所以执行是有前后顺序的。
那么这时候，就可以用信号量来实现多进程同步的方式，我们可以初始化信号量为 0。
具体过程：
可以发现，信号初始化为 0，就代表着是同步信号量，它可以保证进程 A 应在进程 B 之前执行。
跨机器进程间通信方式
同个进程下的线程之间都是共享进程的资源，只要是共享变量都可以做到线程间通信，比如全局变量，所以对于线程间关注的不是通信方式，而是关注多线程竞争共享资源的问题，信号量也同样可以在线程间实现互斥与同步：
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）