今天跟璋儿讨论到系统配置的问题。最常见的做法是由一个进程来维护这些配置，进行读写。其它的进程如果需要set/get某一配置项，需要通过socket发送消息到管理进程。
我想到了android的property机制。其实property就是name&value对，与常见系统中的配置项没有差异。在android系统中，大量使用了property_set和property_get，用来设置和获取某一property。下面来分析一下。
property_set/property_get位于libcutils.so库。任何进程若要调用这两个函数，需要链接libcutils.so。
libcutils.so调用到了__system_property_set和__system_property_get函数，这两个函数位于bionic库中，源代码文件为bionic/libc/bionic/system_properties.c，生成的库文件为libc_common.so。
对于set和get，分别会创建socket，发送消息到服务端。服务端位于init进程中，有一个property_service进程专门负责这个。该service读取socket消息，进行set和get的处理。property_service代码位于system/core/init/property_service.c
在system_properties.c和property_service.c中都用到了共享内存(用mmap实现），这里我开始有些搞不懂：如果用socket机制的话，只需要管理进程来维护内存即可，客户端不许要访问该内存，干嘛要用共享内存呢？
原来，android这样做是为了效率考虑。在system_properties.c的get调用中，可以通过只读方式访问共享内存，直接获取配置。当然了，为了保证get的时候别人不在set，避免读写冲突，get时需要等待一个信号量。对于set，system_properties.c会通过socket发送消息到service端处理，service端增加或者更新property后会wake该信号量。service端以读写方式打开共享内存。
为什么要这样设计呢？因为系统中由大量的get调用，get可以直接访问共享内存，所以访问更快。对于set，需要交给服务端处理，这样开销比较大，因为用到了socket，但因为set调用相对较少，所以问题也不严重。另为，android系统由以ctl打头的property，这种property比较特殊，可以控制服务的运行和停止，将这些控制放在service(即init进程）也就理所当然了！
附上一个框图：
