signal

D-Bus三层架构 D-Bus是一个为应用程序间通信的消息总线系统, 用于进程之间的通信。它是个3层架构的IPC 系统，包括： 1、函数库libdbus ，用于两个应用程序互相联系和交互消息。 2、一个基于libdbus构造的消息总线守护进程，可同时与多个应用程序相连，并能把来自一个应用程序的消息路由到0或者多个其他程序。 3、基于特定应用程序框架的封装库或捆绑（wrapper libraries or bindings ）。例如，libdbus-glib和libdbus-qt，还有绑定在其他语言，例如Python的。大多数开发者都是使用这些封装库的API，因为它们简化了D-Bus编程细节。libdbus被有意设计成为更高层次绑定的底层后端（low-levelbackend ）。大部分libdbus的 API仅仅是为了用来实现绑定。 总线 　　在D-Bus中，“bus”是核心的概念，它是一个通道：不同的程序可以通过这个通道做些操作，比如方法调用、发送信号和监听特定的信号。在一台机器上总线守护有多个实例(instance)。这些总线之间都是相互独立的。 一个持久的系统总线（system bus）： 它在引导时就会启动。这个总线由操作系统和后台进程使用，安全性非常好，以使得任意的应用程序不能欺骗系统事件。它是桌面会话和操作系统的通信，这里操作系统一般而言包括内核和系统守护进程

Dbus-glib使用心得 一、背景介绍 从安全的角度考虑，广泛的使用DBUS进行进程间通讯。 1.优点： DBUS总线分为系统总线与会话总线两类，两者之前不能互相通信，所以任何应用程序不能欺骗系统事件，安全性很好。 2.缺点 l 直接使用Dbus标准接口调用很繁琐，各服务之间各写一套，不易维护也容易出错。 l 接受方法调用端、消息接收端等程序需要非阻塞式（阻塞式的无法多线程DBUS通讯）判断是否接收到DBUS信息，形如： W hile(1) { dbus_connection_read_write (); msg = dbus_connection_borrow_message(conn); if (NULL == msg) { usleep(xxx); continue; } … } 如上所示，多个服务同时运行的情况下，会占用大量CPU时间片，之前就有测试报告应用程序压力运行单一操作的情况下，应用程序会由快跑慢。 因此需要一个稳定可靠的DBUS调用封装，上层统一该封装接口进行DBUS通讯。 二、 D bus-glib介绍 Dbus-glib是GNU标准库，在Dbus接口上封装，方便上层服务与应用更好的使用。其形如一个DBUS代理服务器，由它进行所有DBUS消息的遍历与转发，服务端与消息发送端只需要向DBUS deamon申请注册唯一的DBUS name 、绑定GOBJECT后

D-Bus三层架构 D-Bus是一个为应用程序间通信的消息总线系统, 用于进程之间的通信。它是个3层架构的IPC 系统，包括： 1、函数库libdbus ，用于两个应用程序互相联系和交互消息。 2、一个基于libdbus构造的消息总线守护进程，可同时与多个应用程序相连，并能把来自一个应用程序的消息路由到0或者多个其他程序。 3、基于特定应用程序框架的封装库或捆绑（wrapper libraries or bindings ）。例如，libdbus-glib和libdbus-qt，还有绑定在其他语言，例如Python的。大多数开发者都是使用这些封装库的API，因为它们简化了D-Bus编程细节。libdbus被有意设计成为更高层次绑定的底层后端（low-levelbackend ）。大部分libdbus的 API仅仅是为了用来实现绑定。 总线 　　在D-Bus中，“bus”是核心的概念，它是一个通道：不同的程序可以通过这个通道做些操作，比如方法调用、发送信号和监听特定的信号。在一台机器上总线守护有多个实例(instance)。这些总线之间都是相互独立的。 一个持久的系统总线（system bus）： 它在引导时就会启动。这个总线由操作系统和后台进程使用，安全性非常好，以使得任意的应用程序不能欺骗系统事件。它是桌面会话和操作系统的通信，这里操作系统一般而言包括内核和系统守护进程

　　 D-bus是一个进程间通信的工具，优点不在这里赘述。 　　网上很多关于dbus的帖子都是基于dbus-glib或者QT D-bus的，直接使用dbus的教程比较少。也难怪，因为连D-bus的官网都说：" If you use this low-level API directly, you're signing up for some pain. " 　　但实际上，直接使用D-bus也没有想象中难。本文将对直接使用D-bus做一个介绍。 本文参考了其他一些网站的帖子或者介绍 官网：http://www.freedesktop.org/wiki/Software/dbus/ 经典例子：http://www.matthew.ath.cx/articles/dbus 不错的帖子：http://blog.csdn.net/flowingflying/article/details/4527634 一、概念介绍 　　这里虽然说是概念介绍，其实只是我个人对D-bus的一个理解，不一定完整准确。 １．首先，D-bus可以分成三部分来看， （１）dbus-daemon，一个dbus的后台守护程序，用于多个应用之间消息的转发； （２）libdbus.so，dbus的功能接口，当你的程序需要使用dbus时，其实就是调用libdbus.so里面的接口； （３）高层封装，如dbus-glib和QT

Dbus-glib使用方法说明 一、背景介绍 Phoenix平台从安全的角度考虑，广泛的使用DBUS进行进程间通讯。 1.优点： DBUS总线分为系统总线与会话总线两类，两者之前不能互相通信，所以任何应用程序不能欺骗系统事件，安全性很好。 2.缺点 l 直接使用Dbus标准接口调用很繁琐，且之前Phoenix平台没有统一的DBUS接口封装，各服务之间各写一套，不易维护也容易出错。 l 接受方法调用端、消息接收端等程序需要非阻塞式（阻塞式的无法多线程DBUS通讯）判断是否接收到DBUS信息，形如： While(1) { dbus_connection_read_write(); msg =dbus_connection_borrow_message(conn); if (NULL == msg) { usleep(xxx); continue; } … } 如上所示，多个服务同时运行的情况下，会占用大量CPU时间片，之前就有测试报告应用程序压力运行单一操作的情况下，应用程序会由快跑慢。 因此需要一个稳定可靠的DBUS调用封装，上层统一该封装接口进行DBUS通讯。 二、Dbus-glib介绍 Dbus-glib是GNU标准库，在Dbus接口上封装，方便上层服务与应用更好的使用。其形如一个DBUS代理服务器，由它进行所有DBUS消息的遍历与转发

dbus基本接口 /* * Example low-level D-Bus code. * Written by Matthew Johnson <dbus@matthew.ath.cx> * * This code has been released into the Public Domain. * You may do whatever you like with it. */ #include <dbus/dbus.h> #include <stdbool.h> #include <unistd.h> #include <stdio.h> #include <stdlib.h> /** * Connect to the DBUS bus and send a broadcast signal */ void sendsignal(char* sigvalue) { DBusMessage* msg; DBusMessageIter args; DBusConnection* conn; DBusError err; int ret; dbus_uint32_t serial = 0; printf("Sending signal with value %s/n", sigvalue); // initialise the error value dbus_error

假设有一个生产者线程，一个消费者线程，生产一个，消费一个。我们来看看怎么实现。 #include <pthread.h> #include <stdio.h> #include <stdlib.h> #include <assert.h> int buffer; int count = 0; void put(int value) { assert(count == 0); count = 1; buffer = value; } int get() { assert(count == 1); count = 0; return buffer; } void *producer(void *arg) { printf("producer...\n"); int i; int loops = (int) arg; for (i = 0; i < loops; i++) { put(i); printf("put:%d\n",i); } } void *consumer(void *arg) { printf("consumer...\n"); int i; while(1) { int tmp = get(); printf("%d\n",tmp); } } int main() { printf("begin...\n"); pthread_t p; pthread_create(

本文主要参考《计算机操作系统（第四版）》（西安电子科技大学出版社）以及清华大学操作系统公开课（向勇、陈渝），整理操作系统的基本概念，供自己复习查阅。 信号量机制 进程控制中最重要的一部分便是协调好进程的并发，控制进程同步，最具体的体现就是处理临界资源。信号量机制便广泛应用在临界资源处理方面。 信号量的分类与发展 信号量最初的定义是表示资源的 数目 。 整型信号量 顾名思义，这种信号量就是用一个整型量s表示某临界资源的数目。在初始化时，把s初始化为资源的数目，并限制只能通过原子操作 wait(s) 和 signal(s) 来访问，这两个操作通常也被称为 P 、 V 操作。可代码表示如下： wait(s) { while(s <= 0); --s; } signal(s) { ++s; } 记录型信号量 可以看到，在整型信号量中，只要申请不到资源，就会不断调试，并不符合“让权等待”原则（即让进程处于“忙等”状态），而记录型信号量就可以解决这个问题。 在记录型信号量中，简单的整型量s被扩充为记录型结构体，里面额外保存了一个进程表指针，用于链接所有等待进程。 struct ProcessControlBlock; using PCB = ProcessControlBlock; struct Semaphore { int value; // 资源数目 PCB* processList;

Linux 多线程编程 线程分类 线程按照其调度者可以分为用户级线程和内核级线程两种。 内核级线程 在一个系统上实现线程模型的方式有好几种，因内核和用户空间提供的支持而有一定程度的级别差异。最简单的模型是在内核为线程提供了本地支持的情况，每个内核线程直接转换成用户空间的线程。这种模型称为“1:1线程模型（threading）”，因为内核提供的线程和用户的线程的数量是1:1。该模型也称为“内核级线程模型（kernel-level threading）”，因为内核是系统线程模型的核心。 Linux 中的线程就是“1:1线程模型”。在linux内核中只是简单地将线程实现成能够共享资源的进程。线程库通过系统调用 clone() 创建一个新的线程，返回的“进程”直接作为用户空间的线程。也就是说，在Linux上，用户调用线程和内核调用线程基本一致。 Linux的线程实现是在核外进行的，核内提供的是创建进程的接口do_fork()。内核提供了两个系统调用clone()和fork()，最终都用不同的参数调用do_fork()核内API。当然，要想实现线程，没有核心对多进程（其实是轻量级进程）共享数据段的支持是不行的，因此，do_fork()提供了很多参数，包括CLONE_VM（共享内存空间）、CLONE_FS（共享文件系统信息）、 CLONE_FILES（共享文件描述符表）、CLONE

volatile提醒编译器它后面所定义的变量随时都有可能改变，因此编译后的程序每次需要存储或读取这个变量的时候，都会直接从变量地址中读取数据。如果没有volatile关键字，则编译器可能优化读取和存储，可能暂时使用寄存器中的值，如果这个变量由别的程序更新了的话，将出现不一致的现象。下面举例说明。在DSP开发中，经常需要等待某个事件的触发，所以经常会写出这样的程序： short flag; void test() { do1(); while(flag==0); do2(); } 这段程序等待内存变量flag的值变为1(怀疑此处是0,有点疑问,)之后才运行do2()。变量flag的值由别的程序更改，这个程序可能是某个硬件中断服务程序。例如：如果某个按钮按下的话，就会对DSP产生中断，在按键中断程序中修改flag为1，这样上面的程序就能够得以继续运行。但是，编译器并不知道flag的值会被别的程序修改，因此在它进行优化的时候，可能会把flag的值先读入某个寄存器，然后等待那个寄存器变为1。如果不幸进行了这样的优化，那么while循环就变成了死循环，因为寄存器的内容不可能被中断服务程序修改。为了让程序每次都读取真正flag变量的值，就需要定义为如下形式： volatile short flag; 需要注意的是，没有volatile也可能能正常运行