• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 3273 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.

SYS/BIOS: Does Hwi_disable() also disables SWI and Task scheduler?

Joachim Siegler
Intellectual 765 points
Other Parts Discussed in Thread: SYSBIOS

Hi Community

During troubleshooting a scanned through some SYS/BIOS code [1] and saw that during the Load_getTaskLoad(), Load_getGlobalSwiLoad() and Load_getGlobalHwiLoad() calls Hwi_disable() will be called.

For the Load_getGlobalHwiLoad() call it is straight forward to disable HWIs. But I wonder why the HWI_disable() call is also used in the  Load_getTaskLoad() and Load_getGlobalSwiLoad() functions. I guess it should be also necessary to disable SWIs when calling Load_getGlobalSwiLoad().

Therefore my question is: Does the HWI_disable() call implicitly disables SWIs and Task scheduling? If it is the case, please point my to a document that is mentioning this fact.

Cheers
Jo

 [1] /opt/ti/bios_6_32_05_54/packages/ti/sysbios/utils/Load.c

  • 0
    TI__Mastermind 32475 points

    Jo,

    Yes, the effects of a Hwi_disable() disables Swi's and Tasks too.

    Usually you have an interrupt which executes an ISR which posts a SWI or unblocks a Task which is blocked on a Semaphore.  If you disable interrupts then you have blocked any other ISR from executing thus you have effectively blocked any Swi or Task that could preempt your current executing thread.

    Read  section 3.2.5 of the BIOS_user_guide.pdf that is part of the documentation in your BIOS installation.

    Judah

  • 0 in reply to judahvang
    Intellectual 765 points

    Judah,

    Thanks for the explanation. Just to make really sure, that I fully understand the answer. I my case there are many clocks (ti.sysbios.knl.Clock) are running and execute SWI from time to time. I'm not aware of the mechanism that generates the tick for these clocks. Will the tick for these clocks get blocked by a HWI_disable() call? If it's the case, the execution of the SWI connected to these clocks are effectively blocked too.

    Cheers
    Jo

  • 0 in reply to Joachim Siegler
    TI__Mastermind 32475 points

    Jo,

    Yes, an ISR is generated from a Timer to increment the tick for clocks.  When you call Hwi_disable() it will prevent the ISR from running which prevents the incrementing of the clocks.  So Yes, the SWIs connected to the clocks will also be prevented from executing.

    Judah

  • 0 in reply to judahvang
    Intellectual 765 points

    Hi Judah,

    judahvang said:

    Yes, an ISR is generated from a Timer to increment the tick for clocks.  When you call Hwi_disable() it will prevent the ISR from running which prevents the incrementing of the clocks.  So Yes, the SWIs connected to the clocks will also be prevented from executing.

    According to your answer, a HWI_disable() call doesn't call SWI_disable() implicitly but the SWIs are blocked because of the incrementation of the clocks is blocked. During my code review I found another often used scenario, that I want to discuss with you. Please imagine the following 2 task scenario:

    1. High-priority task is running 
    2. High-priority task calls HWI_disable()
    3. High-priority task posts semaphore SEM1 (low-priority task is pending on this SEM1, therefore Low-priority task gets ready)
    4. High-priority task gets blocked
    5. Task switch to Low-priority task?

    Will the task switch in step 5 in this case happen when HWI_disable() was called before or will the SYS/Bios stay in the blocked High-priority task?

    To complete the discussion and to make it more general, is there any possibility for a context switch in general when HWI_disable() was called?

    Cheers
    Jo

  • 0 in reply to Joachim Siegler
    TI__Mastermind 32475 points

    Jo,

    The Task switch will happen in step 5.  When the currently highest priorty task is running and it gets blocked, the next highest priority task that is ready would automatically run.

    A context switch can occur with Hwi_disable().  Note that step 4 requires you to make a blocking call in your Task, and if you do this then it will cause a context switch.  Even if you didn't post a Semaphore that readied a lower priority Task, if you did step #4, it would switch to the Idle Task.

    Judah

  • 0 in reply to judahvang
    Intellectual 765 points

    Judah,

    Thanks for the explanations. Now I have a clue why for example Load_getTaskLoad() needs only to call HWI_disable() to protect itself against a context switch.

    Cheers
    Jo