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.

  • Resolved

RTOS/TMS320C6748: When is it safe to call Semaphore_pend() from main() ?

Intellectual 570 points
Roy Jackson

Part Number: TMS320C6748

Tool/software: TI-RTOS

Please don't say 'never' !!!

Clearly it would be reckless to call pend() from outside a task if it is going to block, but is it OK to call it provided the count is 1 or more so it will not block? Currently, I have a program doing this and it works, but I want to be sure it's safe and I'm not just being lucky.

If you're curious why anyone would do such a bizarre thing, this is how it came about. The program uses SPI1 to access two different devices (flash memory and an ADC) from two different tasks, and needs to guarantee exclusive access to the SPI so it uses a semaphore with an initial count of 1 as a mutex. So far, so good. Then it turns out we need to read something from the flash from main, before the call to BIOS_start(); The function  that reads the flash pends on a semaphore, reads flash, then posts the semaphore. So (without realising, initially) that function is called once from main, and then repeatedly later on from a task.

And it works! But should it?    Needless to say, I could restructure the program if I have to, but it's a huge upheaval at this stage.

Cheers

Roy

Intellectual 570 points
Roy Jackson
  • Guru 65605 points
    ToddMullanix
    If you use BIOS_NO_WAIT as the timeout, you can call Semaphore_pend from any thread (Task, Swi, or Hwi) and main().

    Todd
  • Intellectual 570 points
    Roy Jackson

    In reply to ToddMullanix:

    Thanks Todd,
    I'm using BIOS_WAIT_FOREVER because I need the task to wait until the other task has finished and released the SPI.

    I must admit I read about using BIOS_NO_WAIT but didn't really understand it. Or rather I didn't understand how that would be useful. Presumably it decrements the semaphore count but never blocks the task, even if the count goes to zero?

    Problem is, I need it to be able to block the task, if it's called from a task. And not to block if it's called from main(). I can guarantee when it's called from main() the resource is always available, so it will never attempt to block. Is that sufficient?

    I realise this is a dodgy thing to ask. Maybe I should just bite the bullet and restructure.

    Cheers
    Roy
  • Guru 65605 points
    ToddMullanix

    In reply to Roy Jackson:

    Hi Roy,

    If you call Semphore_pend with BIOS_NO_WAIT, here is what can happen (for both binary and counting semaphores)
    1. The semaphore count is non-zero (e.g. it's available): Count is decremented by 1 and TRUE is returned. In other words, the caller obtains the semaphore.
    or
    2. The semaphore count is zero (e.g. it's NOT available): Count is not decremented and FALSE is returned. In other words, the caller does not obtain the semaphore.

    You could add a call to determine what context you are in and use the corresponding timeout. The API is BIOS_getThreadType() and the returns are

    enum ThreadType {
    BIOS_ThreadType_Hwi, /*! Current thread is a Hwi */
    BIOS_ThreadType_Swi, /*! Current thread is a Swi */
    BIOS_ThreadType_Task, /*! Current thread is a Task */
    BIOS_ThreadType_Main /*! Current thread is Boot/Main */
    }
  • Intellectual 570 points
    Roy Jackson

    In reply to ToddMullanix:

    Oh cool! Thanks.  I didn't know about BIOS_getThreadType()

    That is excellent, thanks, I can work with that.

    Roy

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.

All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.

Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms of Use of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms of Use of this site. TI, its suppliers and providers of content reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.

TI Worldwide | Contact Us | my.TI Login | Site Map | Corporate Citizenship | mobile m.ti.com (Mobile Version)

TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs and
embedded processors, along with software, tools and the industry’s largest sales/support staff.

© Copyright 1995-2018 Texas Instruments Incorporated. All rights reserved.
Trademarks | Privacy Policy | Terms of Use