• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 101 subscribers
  • Views 1309 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.

HeapMem malloc/free Multithread problem

Kishor Jm
Prodigy 585 points
Other Parts Discussed in Thread: SYSBIOS

Hi,

I'm using these versions

bios_6_34_03_19, ipc_1_25_01_09, xdctools_3_24_03_33, syslink_2_21_00_03 on TI811X platform.

I'm facing problem with HeapMem malloc/free on multiple threads on DSP.

  1. Low priority task calls MessageQ_free
  2. It aquires GateMutex
  3. Preempted by High Priority task
  4. High Priority task calls MessageQ_alloc which seems to corrupt heap queue.
  5. Assert on Invalid Free raised when high priority task calls MessageQ_free 

I understand that by default HeapMem uses GateMutex, so this problem should not occur.

I tried to use a different GateMutex/GateMutexPri as below  but the problem is still there.

var GateMutexPri = xdc.useModule('ti.sysbios.gates.GateMutexPri');
var HeapMem = xdc.useModule('ti.sysbios.heaps.HeapMem');
HeapMem.common$.gate = GateMutexPri.create();

Can you let me know if anything need to do be done to support malloc/free on Multithreaded application.

-Kishor

  • 0
    TI__Guru* 96960 points

    Hi Kishor,

    Yes, HeapMem supports multi-task environments. Are you sure you are calling MessageQ_alloc/free from Tasks and not from a Hwi or Swi. Usually when we hear about behavior like this, it is because of stack overflow, the memory is being corrupted by a bad application pointer, or you are writting past the end of the memory block. Please check ROV for the Task stack usage and also look at HeapMem.

    Todd

  • 0 in reply to ToddMullanix
    TI__Prodigy 585 points

    I found that the high priority task calls RingIO_release which inturn calls a callback notifier function

    And this callback function calls the MessageQ_alloc function.

    I see below from Syslink RingIO doc:

    <<

    RingIO_open() for both reader and writer has been successful. No SysLink API should be called from a callback function registered through the RingIO module. On SYS/BIOS the callback functions are run from ISR context and must not perform any operations that may take a lock or block, which is done by most SysLink APIs. Minimum functionality must be used in the callback functions, most often limited to posting a semaphore on which application is waiting, posting SWI etc

    >>

    But I'm not sure why I don't get a assert about wrong calling context.

    I want to confirm from Syslink team if we can call MessageQ_staticMsgInit and MessageQ_put from this callback. I assume these don't block.

    One more point I would like to mention with using MessageQ_staticMsgInit. When the same buffer is used for send these messages, if a second message is sent

    before first message is received the MessageQ list is corrupted. I think this can be mentioned in MessageQ_staticMsgInit document.

    -Kishor

  • 0 in reply to Kishor Jm
    TI__Expert 7415 points

    Kishor, 

    Looks like the functions you refer to are using system gates etc, so they may block. Since the callback function will be called from a Swi context, it should be non-blocking. 

    Hope that answers your question.

    Gunjan.

  • 0 in reply to Gunjan
    TI__Prodigy 585 points

    Hi Gunjan,

    Thanks for the answer.

    I want to confirm if DSP to DSP messageQ_put can block? I don't see any Gate call in MessageQ_put source code in IPC.

    -Kishor

  • 0 in reply to Kishor Jm
    TI__Expert 7415 points

    Kishor,

    I had a conversation with the Syslink experts and they are of the opinion that MessageQ_put might still be blocking if it uses a blocking synchronizer,  when the message is placed on the receiving queue. 

    By default, whenever you use Syslink, you will get a blocking synchronizer. That is probably why the documentations warns against using any Syslink API in the callback notifier.

  • 0 in reply to Gunjan
    TI__Expert 7415 points

    Kishor,

    I wanted to let you know that we had some more discussions on this topic, and we will respond with some more information soon. It seems like you may be able to use MessageQ_put. Please await a more detailed response.

    Thanks,

  • 0 in reply to Gunjan
    TI__Prodigy 585 points

    Hi Gunjan,

    OK. Please provide it soon.

    -Kishor

  • 0 in reply to Kishor Jm
    TI__Expert 7415 points

    Kishor,

    We need a little more clarification on what exactly you need to know. You mentioned you want to know if MessageQ_put can 'block'. In SYS/BIOS terminology, a blocking call means that the Task may context switch out because it is blocked on something. So do you mean blocking in the SYS/BIOS sense, or do you want to know if the call is non-deterministic ?

    In general, blocking or not, seems to depend on the underlying transport implementation.

    Thanks,

    Gunjan.

  • 0 in reply to Gunjan
    TI__Prodigy 585 points

    Gunjan,

    I want to know if MessageQ_put  can be called from RingIO Callback or not. 

    It's ok if the call is non-deterministic. I suppose that means blocking in SYS/BIOS sense.

    -Kishor

  • 0 in reply to Kishor Jm
    TI__Genius 12025 points

    Kishor,

    On the DSP side, yes; you can call MessageQ_put from the RingIO callback. On the HOST side, no.

    In both cases, you cannot call MessageQ_alloc/MessageQ_free from the RingIO callback.

    Re: an earlier post on MessageQ_staticMsgInit. Reading your post it sounds to me that you are trying to send the same message twice but without waiting to receive the message. You cannot do this. Once you send a message, you loose ownership; you cannot reference the message in any way. Once you receive the message, then you have re-aquired ownership of that message and can send it again. Does this answer your question?

    ~Ramsey