Bash中的$符号的作用是参数替换，将参数名替换为参数所代表的值。对于$来说，大括号是可选的，即$A和${A}代表同一个参数。
${}带冒号的有下面几种表达式： ${parameter:-word}如果parameter为null或者未设置，整个参数替换表达式值为word
${parameter:=word}如果parameter为null或者未设置，整个参数替换表达式值为word，并且parameter参数值设置为word
${parameter:?word}如果parameter为null或者未设置，则打印出错误信息。否则，整个参数替换表达式值为$parameter
${parameter:+word}如果parameter不为null或者未设置，则整个参数替换表达式值为word
${parameter:offset} ${parameter:offset:length}parameter的值的子字符串。
可以理解下下面这几个例子：
${}带！有下面几种表达式： ${!prefix*} ${!prefix@}
将带有前缀为prefix的参数名打印出来
${!name[@]} ${!name[*]}这个是针对name数组的，打印出来name数组有哪些下标
可以理解下下面这几个例子：
${}带正则匹配的几种表达式： ${parameter#word} ${parameter##word}
从头开始扫描word，将匹配word正则表达的字符过滤掉
#为最短匹配，##为最长匹配
${parameter%word} ${parameter%%word}从尾开始扫描word，将匹配word正则表达式的字符过滤掉
%为最短匹配，%%为最长匹配
可以理解下面这几个例子：
${parameter/pattern/string} ${parameter//pattern/string}
将parameter对应值的pattern字符串替换成为string字符串
/表示只替换一次
//表示全部替换
可以理解下面这几个例子：
目前国内的实时操作系统正在如春天般的万物发展趋势一样，充满蓬勃生机。但是多数情况下，各自为战，开发的软件大家得不到有效的共享。有的时候某位作者开发出来了协议栈，但是其他作者却无法使用，或者要使用带来了很大的难度。
协议栈的移植究其根本从3方面考虑来移植。
1 完成协议栈底层驱动的接口。
2 对编译器的移植。
3 对操作系统的接口移植。
对于驱动接口和编译器的移植，是做不了什么的，这个是硬性规定。但是对于操作系统接口的移植，由于大家的实时系统各异，就要花费很多的工作再去封装。这样就浪费了很多的时间。如果各位实时操作系统作者能统一操作系统层面的接口的话，对于软件的共享，以及测试有百利而无一害。具体说明如下：
1 定义一套实时操作系统的抽象层接口。这套抽象层接口首先要能满足国外的一些主流实时系统的封装。比如：
task_create_cn(……….)
{
Ucos3_task_create(……);
}
task_create_cn(……….)
{
threadx_task_create(……);
}
Task_create_cn()
{
Free_rtos_task_create(…….);
}
其它api类推。
2 api 的类型定义不允许使用RAW_U32 或者U32等等类似的类型定义，举例如下：
RET_TYPEtask_sleep_cn(TICK_TYPE time_sleep)
其中的RET_TYPE 和TICK_TYPE需要再次定义。比如：
typedefRET_TYPE TYPE_U32
typedefTICK_TYPE TICK_U32
TYPE_U32和TICK_U32根据不同的编译器再次定义数据类型。
这样做的好处是，这套api可以充分和编译器脱离关系，也可以兼容不同的操作系统api,也可以同时兼容32位和64位系统。
3 函数的命名规则比如可以是名词+动词+后缀名（cn）
4 对于操作系统共通的特性，这套api需要完全支持，对于各操作系统特殊的api，可以实现扩展式的api,这些api是可选的，协议栈移植时不允许使用这些api，用户上层逻辑开发时可以使用这些api。
5 这套api 的价值在于，各家rtos只要封装了这套接口后，协议栈以及驱动这边可以达到高度的统一，如果应用程序也遵循这套api的话，他家rtos也可以瞬间上去。
6 对于api 的功能会有一本手册详细定义各api的功能。
目前操作系统接口比较广泛点的是posix接口，但是这套接口不太适合于rtos开发，比如进程这个概念，目前市场主流rtos 都是不支持的，那进一步比如进程通讯，设置这些api对于rtos都是浮云了。所以跑在老外前面，制定这一套api,对于提高国内rtos的普及以及学习是强有力的直接性的帮助。学习rtos的学者，只需要学习一套api就可以了。开发的工程师只要使用这一套api，就可以达到各rtos的通用,不用再存门户之见。
综上所述只是一家之言，希望大家多多参与，给出意见。欢迎各位rtos大侠，积极交流，争取早日这套api出师。
C++实现线程池。
欢迎转载，转载请注明原出处：http://blog.csdn.net/ithzhang/article/details/9020283
本文介绍的线程池采用C++语言，在windows平台下实现。此版本为Version 1.0，以后还会推出功能更完备的后续版本。本着技术分享的精神写作本文同时公布源代码。欢迎大家指出该线程池存在的问题并对当前性能进行讨论。
适用场景：
1.需要大量的线程来完成任务，且完成任务的时间比较短。
2.对性能要求苛刻的应用，比如要求服务器迅速相应客户请求。
3.接受突发性的大量请求，但不至于使服务器因此产生大量线程的应用。
不适合在以下场景下使用：
1.可能会长时间运行的任务。
2.具有良好的优先级控制。（本线程池仅仅实现了简单的优先级控制，有两种优先级：普通级和高级）。
使用到的数据结构：
任务队列：任务缓冲区，用于存储要执行任务的队列。可以调用线程池成员函数向该队列中增加任务。
空闲线程堆栈：用于存储空闲线程。空闲线程堆栈中会被压入指定数量的线程类对象指针。线程对象个数等于创建线程时初始线程个数。
活动线程链表：用以存储当前正在执行任务的线程。当有任务到来时，线程会从空闲堆栈转移到活动链表中。任务完成，且任务队列中没有任务时，会从活动链表转移到空闲堆栈中。本文中我称其为线程状态转换。
调度机制：
1.向任务队列添加任务后，会检查此时空闲线程堆栈中是否有空闲线程，如有则从任务队列队首取出任务执行。
2.当线程执行完当前任务，准备转移到空闲堆栈时，也会检查当前任务队列是否为空。若不为空，则继续取出任务执行。否则，转换到空闲线程堆栈。