VxWorks信号量是提供任务间通信、同步和互斥的最优选择,提供任务间最快速的通信。也是提供任务间同步和互斥的主要手段。VxWorks提供3种信号量来解决不同的问题。
二进制信号量:最快的最常用的信号量,可用于同步或互斥。
互斥信号量:为了解决内在的互斥问题如优先级继承、删除安全和递归等情况而最优化的特殊的二进制信号量。
计数信号量:类似于二进制信号量,但是随信号量释放的次数改变而改变。
二进制信号量
二进制信号量能够满足任务间的互斥和同步,需要的系统开销最小,因此也称快速信号量。二进制信号量可以看成一个标志,对应资源是可用还是不可用。当一个任务调用semTake ()请求一个信号量时,如果此时信号量可用,信号量会被清零,并且任务立即继续执行;如果信号量不可用,任务会被阻塞来等待信号量。
当一个任务调用semGive ()释放一个二进制信号量时。如果信号量已经可用,释放信号量不会产生任何影响;如果信号量不可用并且没有任务等待使用该信号量,信号量只是被简单地置为可用;如果信号量不可用并且有一个或多个任务等待该信号量,最高优先级的任务被解阻塞,信号量仍为不可用。
互斥
当两个以上的任务共享使用同一块内存缓冲区或同一个I/O设备之类的资源时,可能会发生竞争状态。
二进制信号量可以通过对共享资源上锁,实现高效的互斥访问,不象禁止中断或禁止抢占,二进制信号量将互斥仅仅限于对与之联系的资源的访问,并且比禁止中断和禁止抢占提供更精确的互斥粒度。使用时创建用于保护资源的二进制信号量,初始时信号量可用。
当任务需要访问这个资源时,首先取得这个信号量,所有其它想要访问这个资源的任务将被阻塞。当任务完成了对该资源的访问时,释放该信号量,允许其他任务使用该资源。因此所有对一个需要互斥访问资源的操作由semTake ()和semGive ()对一起来实现。
semTake(semMutex,WAIT FOREVER)
临界区,某一时刻仅被一个任务访问
semGive (semMutex)
同步
信号量另一种通常的用法是用于任务间的同步机制。在这种情况下,信号量代表一个任务所等待的条件或事件。最初,信号量是不可用的。一个任务或中断处理程序释放该信号量来通知这个事件的发生。等待该信号量的任务将被阻塞直到事件发生、该信号量可用。一旦被解阻塞,任务就执行恰当的事件处理程序。信号量在任务同步中的应用对于将中断服务程序从冗长的事件处理中解放出来以缩短中断响应时间是很有用的。
互斥信号量
互斥信号量是一种特殊的二进制信号量,用于解决具有内在的互斥问题:优先级继承、删除安全和对资源的递归访问等情况。
对于一般的操作系统,一般互斥信号量就是二值信号靓量,但VxWoks中有非同寻常的意义。另外一个典型就是,Linux内核也单独设立了互斥信号量。
互斥信号量与二进制不同点在于:
①定义一个互斥信号量时,其已经初始化完毕为可用,它仅用于互斥;
②仅能由取(semTake ())它的任务释放,即由同一个任务申请然后使用完毕后释放;
③因为semTake和semGive是成对出现的,因此不能在ISR 中释放(semGive ())。
优先级继承
优先级倒置发生在一个高优先级的任务被迫等待一段不确定时间,等待一个低优先级任务完成。VxWorks允许使用优先级继承算法,在互斥信号量中使用选项SEM-INVERSION-SAFE ,将使能优先级继承算法,优先级继承协议确保拥有资源的任务以阻塞在该资源上的所有任务中优先级最高的任务的优先级执行,直到它释放所拥有的所有信号量,然后该任务返回到正常状态。因此这个“继承的高优先级”任务受到不会被任何中间优先级任务抢占的保护。
删除安全
另一个互斥问题涉及到任务删除。在一个受信号量保护的临界区,经常需要保护在临界区执行的任务不会被意外地删除。删除一个在临界区执行的任务可能引起意想不到的后果,造成保护资源的信号量不可用,可能导致资源处于破坏状态,也就导致了其他要访问该资源的所有任务无法得到满足。
原语taskSafe()和taskUnsafe ()提供了防止任务被意外删除的一种方法。同时互斥信号量提供了选项SEM-DELETE-SAFE ,使用这个选项,每次调用semTake ( )时隐含地使能了taskSafe(),当每次调用semGive ()时隐含地使能了taskUnsafe ()这种方式,任务得到信号量时得到不会被删除的保护。
递归资源访问
互斥信号量能够被递归地获得。这意味着信号量能够被一个拥有该信号量的任务在该信号量最终被释放之前多次获取。递归对于满足一些子程序即要求能够相互调用但是也要求互斥访问一个资源非常有用。这种情形是可能的,因为系统需要跟踪哪一个任务当前拥有信号量。
计数器信号量
计数器信号量是实现任务同步和互斥的另一种手段,在具体实现上有点差异。计数器信号量除了像二进制信号量那样工作外,还保持对信号量释放次数的跟踪。与二进制信号量不同的时,计数型信号量每次释放,计数器加一;每次获取,计数器减一,当信号量减到0 时,试图获取该信号量的任务被阻塞。
正如二进制信号量,当计数信号量释放时,如果有任务阻塞在该信号量阻塞队列上,那么任务解除阻塞;但是如果信号量释放时,没有任务阻塞在该信号量阻塞队列上,那么计数器加一。
结 论
通过对嵌入式操作系统VxWorks的多任务之间的通信机制的分析可以看出,信号量在实现多任务间的通信、同步和互斥中发挥着重要的作用。因此,深入理解和正确使用VxWorks的信号量,可以提高实时系统中多任务间通信的效率
这时一个中等优先级的task进来:1*访问临界资源*.避免优先级倒置(Priority Inversion):
1,计数信号量可记录信号量释放的次数, SEM_FOREVER), 而不会死锁
semGive(sem_ID)。
其实质是.只能由已经获取了互斥信号量的任务去释放它
semGive(sem_ID).互斥信号量只能用于互斥操作semaphore options */ ,可以用来监视某一资源的使用状况。
2
/。其不同点在于*访问临界资源*。
4。
如果一个任务task1试图删除一个已经被保护起来的任务task2.互斥信号量不支持semFlush()操作可以实现安全删除
}
funA()
{
semTake(sem_ID;在执行semGive()操作之后,并抢占了task1的CPU。这种现象就是先级倒置就可以避免倒置.Deletion Safety(安全删除)
使用,直到task2解除保护(释放掉具有删除保护的互斥信号量)才能完成删除工作。
SEM_INVERSION_SAFE不能与SEM_Q_FIFO配对,此时的表现是低优先级task在高优先级的task2前执行
}
funB()
{
semTake(sem_ID,隐含执行taskUnsafe()操作,隐含执行了taskSafe()操作
}
五.Counting Semaphores(计数信号量)
计数信号量与二进制信号量都可以用于任务之间的同步与互斥:semId = semMCreate(SEM_Q_FIFO SEM_DELETE_SAFE)递归访问。
应用方向:
在上图中。
3,task1的优先级提升与task2一样:在Task对互斥信号量执行semTake()操作并成功占有该信号量之前。
使用semId = semMCreate(SEM_Q_PRIORITY SEM_INVERSION_SAFE)!
2,task2等待task1的资源
funB()
,于是处于Pend状态, SEM_FOREVER),task1则将被阻塞起来。
此时.递归访问
[c-sharp] view plaincopy
InitFun()
{
sem_ID = semMCreate(…),至到task2执行完成
)
区别.中断服务程序(ISR)不可以释放(semGive())互斥信号量。
3
援引CU上一篇帖子的内容:“信号量用在多线程多任务同步的,一个线程完成了某一个动作就通过信号量告诉别的线程,别的线程再进行某些动作(大家都在semtake的时候,就阻塞在 哪里)。而互斥锁是用在多线程多任务互斥的,一个线程占用了某一个资源,那么别的线程就无法访问,直到这个线程unlock,其他的线程才开始可以利用这 个资源。比如对全局变量的访问,有时要加锁,操作完了,在解锁。有的时候锁和信号量会同时使用的”
也就是说,信号量不一定是锁定某一个资源,而是流程上的概念,比如:有A,B两个线程,B线程要等A线程完成某一任务以后再进行自己下面的步骤,这个任务 并不一定是锁定某一资源,还可以是进行一些计算或者数据处理之类。而线程互斥量则是“锁住某一资源”的概念,在锁定期间内,其他线程无法对被保护的数据进 行操作。在有些情况下两者可以互换。
两者之间的区别:
作用域
信号量: 进程间或线程间(linux仅线程间)
互斥锁: 线程间
上锁时
信号量: 只要信号量的value大于0,其他线程就可以sem_wait成功,成功后信号量的value减一。若value值不大于0,则sem_wait阻塞,直到sem_post释放后value值加一
互斥锁: 只要被锁住,其他任何线程都不可以访问被保护的资源
成功后否则就阻塞
以下是信号灯(量)的一些概念:
信号灯与互斥锁和条件变量的主要不同在于”灯”的概念,灯亮则意味着资源可用,灯灭则意味着不可用。如果说后两中同步方式侧重于”等待”操作,即资 源不可用的话,信号灯机制则侧重于点灯,即告知资源可用;没有等待线程的解锁或激发条件都是没有意义的,而没有等待灯亮的线程的点灯操作则有效,且能保持 灯亮状态。当然,这样的操作原语也意味着更多的开销。
信号灯的应用除了灯亮/灯灭这种二元灯以外,也可以采用大于1的灯数,以表示资源数大于1,这时可以称之为多元灯。
1. 创建和 注销
POSIX信号灯标准定义了有名信号灯和无名信号灯两种,但LinuxThreads的实现仅有无名灯,同时有名灯除了总是可用于多进程之间以外,在使用上与无名灯并没有很大的区别,因此下面仅就无名灯进行讨论。
int sem_init(sem_t *sem, int pshared, unsigned int value)
这是创建信号灯的API,其中value为信号灯的初值,pshared表示是否为多进程共享而不仅仅是用于一个进程。LinuxThreads没有实现 多进程共享信号灯,因此所有非0值的pshared输入都将使sem_init()返回-1,且置errno为ENOSYS。初始化好的信号灯由sem变 量表征,用于以下点灯、灭灯操作。
int sem_destroy(sem_t * sem)
被注销的信号灯sem要求已没有线程在等待该信号灯,否则返回-1,且置errno为EBUSY。除此之外,LinuxThreads的信号灯 注销函数不做其他动作。
2. 点灯和灭灯
int sem_post(sem_t * sem)
点灯操作将信号灯值原子地加1,表示增加一个可访问的资源。
int sem_wait(sem_t * sem)
int sem_trywait(sem_t * sem)
sem_wait()为等待灯亮操作,等待灯亮(信号灯值大于0),然后将信号灯原子地减1,并返回。sem_trywait()为sem_wait()的非阻塞版,如果信号灯计数大于0,则原子地减1并返回0,否则立即返回-1,errno置为EAGAIN。
3. 获取灯值
int sem_getvalue(sem_t * sem, int * sval)
读取sem中的灯计数,存于*sval中,并返回0。
4. 其他
sem_wait()被实现为取消点,而且在支持原子”比较且交换”指令的体系结构上,sem_post()是唯一能用于异步信号处理函数的POSIX异步信号 安全的API。
----------------------------
线程同步:何时互斥锁不够,还需要条件变量?
假设有共享的资源sum,与之相关联的mutex 是lock_s.假设每个线程对sum的操作很简单的,与sum的状态无关,比如只是sum++.那么只用mutex足够了.程序员只要确保每个线程操作 前,取得lock,然后sum++,再unlock即可.每个线程的代码将像这样
add()
{
pthread_mutex_lock(lock_s)
sum++
pthread_mutex_unlock(lock_s)
}
如果操作比较复杂,假设线程t0,t1,t2的操作是sum++,而线程t3则是在sum到达100的时候,打印出一条信息,并对sum清零. 这种情况下,如果只用mutex, 则t3需要一个循环,每个循环里先取得lock_s,然后检查sum的状态,如果sum>=100,则打印并清零,然后unlock.如果sum&lt100,则unlock,并sleep()本线程合适的一段时间.
这个时候,t0,t1,t2的代码不变,t3的代码如下
print()
{
while (1)
{
pthread_mutex_lock(lock_s)
if(sum<100)
{
printf(“sum reach 100!”)
pthread_mutex_unlock(lock_s)
}
else
{
pthread_mutex_unlock(lock_s)
my_thread_sleep(100)
return OK
}
}
}
这种办法有两个问题
1) sum在大多数情况下不会到达100,那么对t3的代码来说,大多数情况下,走的是else分支,只是lock和unlock,然后sleep().这浪费了CPU处理时间.
2) 为了节省CPU处理时间,t3会在探测到sum没到达100的时候sleep()一段时间.这样却又带来另外一个问题,亦即t3响应速度下降.可能在sum到达200的时候,t4才会醒过来.
3) 这样,程序员在设置sleep()时间的时候陷入两难境地,设置得太短了节省不了资源,太长了又降低响应速度.真是难办啊!
这个时候,condition variable内裤外穿,从天而降,拯救了焦头烂额的你.
你首先定义一个condition variable.
pthread_cond_t cond_sum_ready=PTHREAD_COND_INITIALIZER
t0,t1,t2的代码只要后面加两行,像这样
add()
{
pthread_mutex_lock(lock_s)
sum++
pthread_mutex_unlock(lock_s)
if(sum>=100)
pthread_cond_signal(&cond_sum_ready)
}
而t3的代码则是
{
pthread_mutex_lock(lock_s)
while(sum<100)
pthread_cond_wait(&cond_sum_ready, &lock_s)
printf(“sum is over 100!”)
sum=0
pthread_mutex_unlock(lock_s)
return OK
}
注意两点:
1) 在thread_cond_wait()之前,必须先lock相关联的mutex, 因为假如目标条件未满足,pthread_cond_wait()实际上会unlock该mutex, 然后block,在目标条件满足后再重新lock该mutex, 然后返回.
2) 为什么是while(sum<100),而不是if(sum<100) ?这是因为在pthread_cond_signal()和pthread_cond_wait()返回之间,有时间差,假设在这个时间差内,还有另外一 个线程t4又把sum减少到100以下了,那么t3在pthread_cond_wait()返回之后,显然应该再检查一遍sum的大小.这就是用 while的用意
欢迎分享,转载请注明来源:夏雨云
评论列表(0条)