Alternative to passing context as a parameter

**Jayasuriya** · 08-23-2008

Hi,

I am working on a C application. The application can have multiple instances. In each instance of the application, there are 4 components. One of the four components will have a structure that needs to be made available to the other 3 components.

Multiple instances of the application (due to reasons beyond my control) will use SHARED memory for globals. So, if a global variable was to be used, the multiple instances of the application (with 4 components each) would interfere with each other via the global variable - as far as I can tell. The other way I can think of is to pass the structure to every function call. So the structure can propagate deep into the call stack.

So,
1) Global variable - potential interference from multiple instances of application
2) Passing the struct as a parameter in EACH and EVERY function call in each component - tedious and ugly

What do you guys think? Any suggestions?. Thank you!

**matsp** · 08-23-2008

Passing context as a parameter is definitely a good proposition - yes, you will be passing it around a lot, but as long as it's a pointer to the context, it should be fine doing that - not much overhead at all.

Another possibility is to have a "handle", such as an integer index into the relevant context - again, you will probably be passing this variable around a lot too.

Which is better will depend on your design, really.

Passing context as a parameter (pointer to struct, generally) is a very common solution, and if you ever work on for example device drivers in Windows, nearly every single function takes a "PDEV" parameter, which is a pointer to a DEV structure (device dependent data - MS accepts one when the driver is initialized, and then passes it along whenever the driver is called - and you usually need it everywhere in the driver except for the odd rare utility function [e.g. some function that calculates some common calculation] ). Linux device drivers have a very similar design - the name is different, but the concept is certainly the same.

--
Mats

**Jayasuriya** · 08-23-2008

Hi Mats,

Thank you for your reply. So, based on your response, passing the context seems to be a common way of doing it. I guess there is no way of avoiding it then. I guess it is very similar to how C++ passes the "this" pointer implicitly.

Now, is the shared memory for global variables (wrt multiple instances of the application) common? How are the local variables guaranteed to be safe? - i.e. how are the stack pointers used by different instances of the application guaranteed to be different, when they clearly interfere in the global space? Finally, does this apply to "static local variables" in functions as well?

Thank you!

**matsp** · 08-23-2008

I expect that this is some sort of embedded system.

No, it is not common to share global data. Local static normally end up in the same chunk of memory as regulars - the only difference is that the name isn't available to other functions.

Stacks, to work correctly, must be unshared.

--
Mats

**Jayasuriya** · 08-23-2008

Hi Mats,

It's actually a Windows system. And isn't local static variable persistent and retain its value? i.e. it has local scope but has the lifetime of the program.

I "presumed" it would be treated as a global (life-time wise), but the compiler enforces local scope rules...

Thanks.

Thread: Alternative to passing context as a parameter

Thread Tools

Search Thread

Display

Alternative to passing context as a parameter

Similar Threads

Screwy Linker Error - VC2005

Dikumud

Please Help - Problem with Compilers

Scope And Parameter Passing

typecasting data for parameter passing