vishalrt@sify.com wrote:
> I am working on VxWorks 5.5 for ppc (MPC8xx) platform. Can someone
> please tell me asap whether a call to taskLock() can cause a higher
> priority task to start executing? In other words, would a call to
> taskLock() cause a reschedule?
>
> Consider another scenario, wherein there are multiple tasks with
> different priorities. If one of these tasks calls the taskLock() API,
> and then pends on a resource (semaphore or queue) or calls the
> taskDelay() API, whether any other active task will start executing, or
> no tasks would execute until taskUnlock() is called? (I know this is
> not the right thing to do, but i want to know what is the result if
> this is the case.) In case other task starts execution, whether all
> tasks would be locked until taskUnlock() is invoked, i.e. when this
> other task starts executing, would the taskLock() that was called by a
> different task still have an effect?
Hi,
There was a discussion on this arised previously.I am pasting it for
your info:
sumit.sharma@wipro.com (sumit.sharma@wipro.com)
53)Hi Vxworks Users,

I have small confusion regd taskLock and taskunlock APIs. Here is the
small descrip of taskLock APi from the Ref Manual...

/**************/
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 with taskUnlock( ); 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 until taskUnlock( ) has been
called as many times as taskLock( ).
/************/

If a task of prio X does taskLock and after that gets blocked (either
waiting for resource, or taskDelay..), does it mean that unless that
"blocked task" **unblocks**, no other task in the system (either of
same prio, or less prio..) will execute...

As the first line of descr says, it disables context switching!!!!!
that is why this confusion????

pls give your comments....

thx, sumit

Martin Roth (bmr006@email.mot.com)
The taskLock() system calls are much easier to understand as changing
the
priority of the task to highest priority.


If the task that performed taskLock() is further being blocked or gives

up
the CPU , - the next ready task will replace it.
(Consider the task that performed taskLock() as the task that raised
itself
the priority to highest one)

If further the blocked task becomes ready - it will gain the CPU at
once,
because it is the highest priority task.
(Again, consider the task that performed taskLock() and was blocked as

the
task with the highest priority)

I do not know how is the taskLock() service implemented in Vxworks ,
but I
would not be surprised if Vxworks raises the priority to highest on the
first
taskLock() call within the task. In the same way it recovers the
priority
on the corresponding taskUnlock().

Martin Roth
Motorola Communications, Israel

Joe Durusau (durusau_novirus@bellsouth.net)
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

John (john_94501@yahoo.com)
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).

There is some information about using taskLock() for more advanced
things in the Cookbook (see
http://www.bluedonkey.org/cgi-bin/tw..._the_Scheduler
for more information).

HTH,
John...