• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 100 subscribers
  • Views 1451 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Semaphore or Raise and Lower Task Priority?

MattB
Expert 2025 points

Hi,

I have some code which runs once each time an event occurs. I've got this code in tasks because I need to use locks.

My first thought was to use semaphores. The hardware interrupt handler posts a semaphore and the task pends on a semphore. For example:

Void TaskFxn(Void)
{
    for (;;)
    {
        SEM_pend(&sem, SYS_FOREVER);
        ...
    }
}

But then I had another thought and wondered if raising and lowering the task priority was a better solution. The hardware interrupt handler sets the task priority and the task sets its own priority to -1 when it has finished. For example:

Void TaskFxn(Void)
{
    for (;;)
    {
        ...
        TSK(&tsk, -1);
    }
}

Both methods seem to work for me but I wondered if anyone had any thoughts about which is the better solution.

I'm not sure what better means in this case!!!

The application has several examples of this and in one case it is necessary to pass some information from the interrupt handler to the task so in this case I think the most obvious solution is to use a mailbox.

Thanks,

Matt

  • 0
    TI__Guru* 96960 points

    Hi Matt,

    Here's my 2 cents (note: I did not do any benchmarking, so take the performance/footprint comment with a grain of salt).

    From a performance and footprint standpoint, playing with the TSK levels might be slightly better. From a support and scalability standpoint, I think the semaphore approach is the better way to go. Once you start having multiple TSK being managed this way, debugging issues or dead-lock cases might get difficult. I would not be surprised if this approach also confuses the execution graph in RTA (not sure if you are using this or not).

    While it might not apply in your case, using a SEM allows for counting or binary notification. The TSK_setpri is a binary approach (i.e. you know that level has been raised, but you don't know how many times TSK_setpri was called). So SEM gives you more flexibility.

    Regarding passing information, MBX is a good general purpose approach. Note: internally MBX uses SEM and QUE. MBX copies data on both the sending and receiving side. So if you have lots of data, you probably want to pass the pointer in the MBX instead of the entire contents.

    Hope that helps.

    Todd

  • 0 in reply to ToddMullanix
    Expert 2025 points

    Hi Todd,

    I like your summary, it makes sense to me!

    I think you're suggesting that using semaphores is the most common and obvious solution. I'm all in favour of using common and obvious techniques (while understanding possible alternatives); in this application I think any cycles saved by using task priority shifting are going to be pretty insignificant!

    Thanks,

    Matt

  • 0
    Prodigy 170 points

    MattB said:

    I have some code which runs once each time an event occurs. I've got this code in tasks because I need to use locks.

    What is it about the use of locks that requires the use of a TSK rather than a SWI?  Is it because of resource contention and the need to halt the task while waiting on a shared resource (SWIs cannot be halted)?

     

    -- bradley

  • 0 in reply to Brad Baker
    Expert 2025 points

    Brad Baker said:
    What is it about the use of locks that requires the use of a TSK rather than a SWI?

    Err...

    From the DSP/BIOS 5.x Reference Guide LCK_pend description:

    "LCK_pend should not be called from a SWI or HWI thread."

    Have I misunderstood??

    Thanks,

    Matt

  • 0 in reply to MattB
    Prodigy 170 points

    MattB said:
    From the DSP/BIOS 5.x Reference Guide LCK_pend description:

    "LCK_pend should not be called from a SWI or HWI thread."

    Have I misunderstood??

    I don't think so.  I was just trying to understand your use of TSKs as opposed to SWIs.  You are using the LCK mechanism for common resource protection which cannot be used in SWIs. If you are using SWIs then the SWI_raise() and SWI_restore functions can be used to implement the Highest Locker Protocol (HLP) to protect a resource shared among threads of differing priorities.  HLP is used for Rate Monotonic or Deadline Monotonic scheduling algorithms to protect common resources.

    -- bb

  • 0 in reply to Brad Baker
    Expert 2025 points

    That's an interesting option. I probably don't want to go changing what I've got now but I'll bear it in mind as this application expands!

    Thanks,

    Matt