Information regarding Syslink Shared region

Pranjal,

To add a little bit to the information that Murat has given ...

Pranjal Chakraborty said:

1. How does a user decide who should be the owner of a shared region. Is there a dependency on which core starts execution first. If yes, is there any documentation i can read through

The owner of the SharedRegion matters when you are setting createHeap to TRUE. The SharedRegion is used for communication and sharing data between two or more cores. Within these cores, it is important that you set the SharedRegion to be the one that starts execution first, and ends execution last, in other words, the 'owner' between the two cores. This is because the 'owner' of the SharedRegion creates the heap in the SharedRegion in its Ipc_start function, whereas the non-owner will open a handle to the heap only when it calls Ipc_attach to attach to the 'owner' core of the SharedRegion. Ipc_start is a necessary condition for doing any IPC with any cores. Consider the situation below:

Core 0 is owner of the SharedRegion 1, which it shares with Core 1. Core 0 also interacts with Core 2, through the same SharedRegion 1.

Core 0 code:

Ipc_start

Ipc_attach (core 2)

<Do IPC with core 2>

... core 1 now starts execution ...

Ipc_attach (core 1)

<Do IPC with core 1>

In the above situation, if core 1 is set to be the owner of SharedRegion 1, on core 0, it won't be able to do IPC with core 21 using SharedRegion 1 heap, since the heap is not yet created ... it will get created when core 2 calls Ipc_start. This is a problem in the system design. Hence, in this situation, having core 0 be the owner is better, since it would create the SharedRegion 1 heap in Ipc_start, and be able to start using it with core 2.

Similarly, if the owner of the SharedRegion ends execution while the others are still doing IPC using the SharedRegion, it will cause the other cores to crash.

In general, it is easiest to decide that the owner of the shared region is the core that starts execution first and ends execution last. When ARM A8 core running Linux is present, it's the easiest to determine that it's the owner, since it loads/starts as well as stops the slave cores. Hence it's safest to keep the A8 as the owner for all SharedRegions in this situation.

Pranjal Chakraborty said:

Hi ,

I have some fundamentals questions about syslink shared region.Here are the questions:

2. If A8 does the SharedRegion_setEntry, it is necessary for another core to do the SharedRegion_setEntry. My questions is if all the shared memory section owner is A8 and A8 starts executing first, if A8 does SharedRegion_setEntry, shouldn't the information about shared region be available for all other cores?

3. If i have 2 application and in the first application i do a SharedRegion_setEntry, then is it necessary to do SharedRegion_setEntry in the second application again?

Yes, as Murat said, the SharedRegion_setEntry takes the local virtual address as the base address. It only adds the information into the local table and makes the SharedRegion available in this context only. It does not go on to the other slaves and set the information on slaves as well. While I can see how such a behavior would be useful, it is more complex than just adding the information into the other slaves. It includes determination of which slaves actually need this SharedRegion, possibly configuring the slave MMU to make this region accessible to it, and then sending a message to the slave so that it can call SharedRegion_setEntry on this region with the provided slave virtual base address. This would require some sort of server running on the slave to handle these requests. Hence it is left to the application to determine the best time and method to do this for the desired slaves only.

If you have 2 applications already running, and now one application does a SharedRegion_setEntry, it gets set in the current application context only. So it will not be available in application 2 context. You will need to call SharedRegion_seteEntry in the second application as well to pull the information into its context. However, if the first application calls SharedRegion_setEntry before the second application starts running, when the second application calls SysLink_setup, it pulls up the information of all currently set SharedRegion entries into its context during this function. So in this latter case, you don't have to call SharedRegion_setEntry in the second application. This latter method is preferred.

Actually, the method that's the most preferred and the easiest to do, is for you to not call SharedRegion_setEntry dynamically at all. If you want any extra SharedRegion, if you set it statically in the cfg file of the slave (any slave), it gets automatically pulled into and mapped into all processes that may run after that on A8, and you don't need to call SharedRegion_setEntry explicitly on the A8 at all. You can simply call SharedRegion_getHeap and start using the heap for your shared memory allocations. This is the method we suggest as the easiest to use.

Pranjal Chakraborty said:

4. In the file HeapMemMP.c,if my execution is stuck in the while loop in the function ti_sdo_ipc_heaps_HeapMemMP_getStats, what could be possibly have gone wrong.This function is getting internally called for a application call of SharedRegion_getHeap. I have confirmed that the call to SharedRegion_getHeap has a proper shared region index.

Copy pasting the function here

 

Void ti_sdo_ipc_heaps_HeapMemMP_getStats(ti_sdo_ipc_heaps_HeapMemMP_Object *obj,
        Memory_Stats *stats)
{
    IArg key;
    ti_sdo_ipc_heaps_HeapMemMP_Header *curHeader;
   
    stats->totalSize         = obj->bufSize;
    stats->totalFreeSize     = 0;  /* determined later */
    stats->largestFreeSize   = 0;  /* determined later */

 

    key = GateMP_enter((GateMP_Handle)obj->gate);
   
    if (obj->cacheEnabled) {
        Cache_inv(&(obj->attrs->head),
                sizeof(ti_sdo_ipc_heaps_HeapMemMP_Header), Cache_Type_ALL,
                TRUE);
    }

 

    curHeader = SharedRegion_getPtr(obj->attrs->head.next);
   
    while (curHeader != NULL) {
        /* Invalidate curHeader */
        if (obj->cacheEnabled) {
            Cache_inv(curHeader, sizeof(ti_sdo_ipc_heaps_HeapMemMP_Header),
                      Cache_Type_ALL, TRUE);
        }
        stats->totalFreeSize += curHeader->size;
        if (stats->largestFreeSize < curHeader->size) {
            stats->largestFreeSize = curHeader->size;
        }
        curHeader = SharedRegion_getPtr(curHeader->next);
    }
  
    GateMP_leave((GateMP_Handle)obj->gate, key);
}

The execution is hung in the while (curHeader != NULL) loop. Please note that it is not consistant. Some time i see this happening immediately aftre i start the application and some time pretty late. Are you aware of any issue like this? I am using syslink 2_00_02_80 and ipc 1.23.03.31 released with the latest SDK 2.1.59 package.

This is most likely due to some issues in the ownershp of the SharedRegion, or the SharedRegion_setEntry (if called dynamically) not having completed successfully at the correct time. The different behavior at different times suggests that some synchronization in the order of SharedRegion heap creation vs. opening is causing the issues. I suggest you use the methods I have mentioned above for SharedRegion usage and see if you still see the issues.

Regards,
Mugdha