Pipe Name Collision Discussion

[pcooksey]

Describe the bug
In https://github.com/nasa/cFE/blob/master/docs/cFE%20Application%20Developers%20Guide.md

Although the Pipe names will not collide with other Application Pipe names in the cFE, the Developer/Operator could become confused if every Application named their Pipe(s) "MY_PIPE". It should be noted, however, that all Pipes for a single Application must have unique names.

This doesn't seem to be true since when I add two apps that try to have the same pipe name I get a failure.

To Reproduce
If I use the same .so file in my startup script but change the app name of the second one:

CFE_APP, /cf/App.so, AppMain, App,    80,  16384, 0x0, 0;
CFE_APP, /cf/App.so, AppMain, App2,  80,  16384, 0x0, 0;

I get the following error:

EVS Port1 66/1/CFE_SB 62: CreatePipeErr:OS_QueueCreate failed, name taken (app=App2, name=App_PIPE)

as they are both trying to make the same "App_PIPE".

Expected behavior
I thought given the text that the pipe names would still be unique to that application.

Code snips
N/A

System observed on:
Laptop
Distributor ID: Ubuntu 18.04.4 LTS
Versions:cFE 6.7.7.0, OSAL 5.0.6.0, PSP 1.4.4.0

Additional context
N/A

Reporter Info
Philip Cooksey
NASA Ames (KBR)

[lethuillierg]

My reading of the developer's guide is different.

I understand the sentence “all Pipes for a single Application must have unique names” as an application requirement (therefore, a mandatory rule that the developer must observe), not a behavior that should be expected from the cFE. Following this interpretation, when a developer creates an application, they should ensure that each pipe related to this application has, among other things, a unique name. More specifically, each time a CFE_SB_CreatePipe is called by the application, the pipe name provided by the developer is required to differ from the previous ones used by this application.

In your example, I do not see the use of multiple pipes by a single instance (i.e. one object loaded and initialized) of an application, but rather an attempt to create two instances of the same application. Doing so implicitly delegates the responsibility of the uniqueness of the pipe names to the cFE. Therefore, and beyond the naming issue, it seems to me that your observation interestingly raises the more general question of multi-instantiability of an application.

But, of course, this is only an interpretation.

[jphickey]

Indeed, the pipe names must be unique across an instance of CFE. If multiple instances of the same application are being created, then that application must itself create unique names for its pipes per-instance. For example, it can call CFE_ES_GetAppName() to get its own name and modify the string accordingly.

The same uniqueness requirement exists for MID's -- the published TLM stream of each instance needs to use a different ID.

Also worth noting that starting multiple instances of the same app isn't officially supported, at least the way suggested in the description. The CFE doesn't distinguish between "loading" and "starting" an app - they are combined (there is a separate enhancement ticket about this) and this affects things like app reload command etc. Loading the same module more than once isn't supported universally across RTOS's, but furthermore will become problematic if you need to reload the app later.

The alternate approach if you need to have more than once instance of a particular service is to create an app that has multiple child threads, and the child threads do the actual work. This way its still one "app" from a CFE perspective of restart/reload commands.

[pcooksey]

Thank you for the feedback!

Ah, I see my mistake was interpreting Application to equal App. In my mind, I thought that cFS was already doing something like the addition of the CFE_ES_GetAppName() to the pipe name.

@jphickey, that is very good to know as we were planning on using the same app two times with different configuration variables. I'll pass along the multiple child thread approach.

I think this issue can be closed. Thanks again!

[jphickey]

FWIW, I would still recommend update the line in the documentation that says:

Although the Pipe names will not collide with other Application Pipe names in the cFE

This not correct, because pipe names WILL conflict with other application pipe names within the cFE. It is actually OSAL that enforces uniqueness of queue names which underpin the SB pipes.

[skliper]

I'll open a new issue to update the documentation, I'd like to leave this one in history as a question/discussion.