taskLock使用注意

 

This routine disables task context switching. The task that calls this routine will be the only task that is allowed to execute, unless the task explicitly gives up the CPU by making itself no longer ready. Typically this call is paired withtaskUnlock( ); together they surround a critical section of code. These preemption locks are implemented with a counting variable that allows nested preemption locks. Preemption will not be unlocked untiltaskUnlock( ) has been called as many times astaskLock( ).

 

1. 该函数禁止任务切换

2.该函数不能禁止中断

3.如果本身任务自动放弃CPU，不再处于ready状态，则其他任务可以执行

4.该函数支持嵌套taskLock

5. taskLock()和taskUnlock()之间不应该有taskDelay 函数或者阻塞函数的调用(例如printf,malloc---该系统函数显然也不能在中断调用)

 

The part after the comma say it all ..."Unless the task makes itself
unready..." TaskLock should never be called unless you have all
the resources you need, and there should never be a taskDelay nor a
blocking call inside a 'taskLock...taskUnlock' pair, but if you
are dumb enough to do it, your taskLock doesn't do anything.

Speaking only for myself,

Joe Durusau

Unless of course you know exactly what you are doing. There are some
uses for blocking while scheduling is locked, but I agree that doing
so unless by design is bad. If you don't understand what
taskLock()/taskUnlock() are doing (or for that matter
intLock()/intUnlock() which behave in a similar way on most CPUs) then
it is best to stick to the simple rule of never doing anything that
could block while you are holding the lock.

Examples of things that can block that beginners often don't realise
could are:

   * printf

   * malloc & free

   * logMsg (which will block unless called from an ISR)

Obviously, you can use things like semGive() OK inside the lock
(semGive() does not block) and also any normally blocking call with a
NO_WAIT timeout value (making it a non-blocking call).