• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 99 subscribers
  • Views 350 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.

SWI_delete() question

Jordon
Intellectual 635 points
Other Parts Discussed in Thread: SYSBIOS

Hello,

A few questions regarding dynamically created SWIs and SWI_delete()...

We have a potential scenario where a dynamically created SWI is preempted by a higher priority SWI. This higher priority SWI then deletes the preempted SWI. Will the SWI Manager reschedule the preempted/deleted SWI so it may run to completion?

Also of note, we have been creating and deleting SWIs from within another SWI for a long time. The BIOS literature says you can NOT call SWI_create() and SWI_delete() from a SWI. How is this working for us?

Thanks in advance.

  • 0
    TI__Mastermind 32475 points

    Hi,

    Deleting a pre-empted SWI is generally not a good idea and can have unknown consequences.  When a SWI is pre-empted, its context is also saved unto the ISR stack, so if you delete the SWI, I can imagine that the ISR stack gets "out of sync" so to speak.  I believe the SWI is removed from the list of SWIs ready to run so it will not be reschedule to run.

    The problem with creating SWIs from a SWI is that if you have a memory allocator which can block, this is not going to work.  Its probably working for you because in your case, the allocation of memory never blocks.  In SYSBIOS 6.xx we have tighten this a bit and you won't actually be allowed to create from a SWI unless your memory allocator has the right gate protection.

    Judah

  • 0 in reply to judahvang
    Intellectual 635 points

    I do not believe that the deleted SWI is taken off the list to be rescheduled, at least we have shown this to be true. Did you test this? We are using BIOS 3.33.01. Thanks.

  • 0 in reply to Jordon
    TI__Mastermind 20805 points

    Can you please provide your BIOS version.  The 3.33.01 version you quote above doesn't exist.   Also, which device are you running on?

    In DSP/BIOS 5.x, it was not allowed to call SWI_delete() from HWI or SWI threads.  

    Can you explain the use case where you want to delete a lower priority running Swi from a higher priority Swi?    We might be able to come up with an alternative solution.   I really don't think the design supports deleting a running Swi.  If it works, it's by accident and there may be some holes.

    Thanks,
    -Karl-

  • 0 in reply to Karl Wechsler
    Intellectual 635 points

    I apologize it is 5.33.03.

  • 0 in reply to Jordon
    Intellectual 635 points

    OMAP 5910 (c55x core), BIOS 5.33.03

    - we plan to wait until all the lower priority SWIs run to completion before the delete(). Anyway that is our concept. We had been working fine but now we have a SWI that takes a long time to run to completion so now we are hitting this scenario. We have been running this design for a long time.

    Thanks. Jordon

  • 0 in reply to Jordon
    TI__Mastermind 20805 points

    The only way to safely know that a SWI has run to completion is to do the delete from a lower priority SWI.   Maybe reserve a single SWI at priority 1 (0 is reserved for the OS in BIOS 5.x) that does the delete.   Make all other SWIs priority 2 or greater.  The only time that priority 1 SWI can run is if higher pri SWIs are not running.  You should consider adding a SWI_disable/restore around the call to SWI_delete(). 

    -Karl-