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.

LCK_pend to GateMutex_enter

Other Parts Discussed in Thread: SYSBIOS

Hello,

As per the DSP/BIOS to SYS/BIOS migration document, the "LCK" module is to replaced by the "GateMutex" module.  But I see that functionality of the two modules do not have a one to one mapping. 

For example, when calling LCK_pend() we can specify whether we want to wait for a certain time period before a resource is available or not.  But this concept of "timed wait" is missing in the "GateMutex" module.  Can you please help me in understanding the method by which the LCK module can be ported to the GateMutex module.

 

Thanks.

Divya

  • Divya,

    It's true that you may have to implement with something different than GateMutex.  Is what you are implementing running within a task thread?

  • Yes David.  The application has multiple tasks and I am trying to lock a resource before updating/modifying it.  Which module in SYS/BIOS can be used to peform this?

    Thanks.

     

  • Hi,

    With SYS/BIOS we decided to not have a timeout on the Gate_enter() call. We felt that the Gate module should be used strictly as a fast critical region management module. Adding in a timeout would increase the number of cycles and make for more complicated code.

    Gate (like LCK) had the idea of ownership. So you can make nested enter (pend) calls without blocking if you are calling from the same Task. Do you require this functionality? If not, you should be using Semaphore directly. If you do, you can look in the <sysbios_install_dir>/packages/ti/bios/support/Lck.c file. This shows how we did the ownership in the pend and post. You could write a module with the similar functionality on top of Semaphore.

    Todd

  • Todd,

    Forgive me for re-opening this, but I would like to make a few points about the need for a timeout in the mutex API

    First, waiting forever is not acceptable in many real time applications.  We make it a habit never to have any "forever" loops or any wait that doesn't have an associated timeout.  If a timeout occurs, we always log it as an important error, but we always try to keep the system running.

    Second, the new priority inheritance feature of Gate_MutexPri is very important.  Nothing like it is available with semaphores.  We hate to give up this important advance over the DSP/BIOS in order to get the benefit of a timeout.

    Third, the timeout feature would cost very little to the user who actually wants to wait forever.  The overheads won't accrue to anyone who doesn't use the feature.

    Fourth, the ability to try for ownership but return immediately if it can't be obtained has some value and should be retained.

    Fifth, the existing SYS/BIOS implementation of Semaphores seems to have a flaw that may not be too important in signalling applications, but does seem significant if the Semaphore is used for a Mutex.  The list of pending tasks does not appear to be maintained in priority order (as it is with Gate_Mutex).  This imposes another penalty on those who try to implement a mutex timeout via semaphores.

    Could you please reconsider this?