Urgent Questions on taskLock() API - VxWorks

This is a discussion on Urgent Questions on taskLock() API - VxWorks ; 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 ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Urgent Questions on taskLock() API

  1. Urgent Questions on taskLock() API

    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?


  2. Re: Urgent Questions on taskLock() API


    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...


+ Reply to Thread