Globar Variables in Shared Libraries

when a shared library exports some global variables: are those variables shared among all processes or does each process get its own copy of the variables?

so the question is: if process 1 writes to a global variable of a shared library, and process 2 reads from that variable - does process 2 read what process 1 wrote? id say no.

A global variable is a global variable.
Meaning anything that can access it, can change it. So if one thing changes it, it is also changed in the other.

>> id say no.
You'd be correct. Each process/dll gets its own copy of the global.

gg

Oh processes I really got to start reading the whole post ;)

thx for reply

but is it also possible to share one instance of global vars of some shared libary among all processes?
i mean do commonly used systems (windows, linux, ...) have support for that?


edit:
don't tell me how to find a work around - i dont need it anyway - i am just writing a little script language with some library support - and i just want to know how far i could go :D

Both Linux and Windows support many types of inter-process communication (IPC), one of which is the concept of "shared memory" that allows multiple processes to have acces to the same chunk of memory.

In other words - yes.

gg

and another thingy:

library functions who want to access "their" global variables cant use absolute or relative addresses to them - they need to use pointers since the globals could be in different locations in different processes.

so is something like:

Code:

---

int gv;

int func() {
  return gv;
}

---

actually rewritten as:

Code:

---

struct GLOBALS {
  return gv;
};

int func(struct GLOBALS *p_g) {
  return p_g->gv;
}

---

so do library functions depend on that the pointer to the globals they need is in some register or on the stack?

or am i completely wrong?

>> library functions who want to access "their" global variables...
Access to variables within a library will always be on a per-module basis (process or dll). It doesn't matter if the global is a pointer or a structure or within a structure.

The only way to have a "PC-global" variable is to use some form of IPC. For example, one easy form of IPC is to simply use files.

gg

uh i think you didnt read really read my question :D

i asked wheter all library functions which need globals are actually rewritten by the compiler.

as all methods (member functions of classes) are "rewritten" so that they have the this pointer passed as first argument.

MyClass::MyMethod(void);
basically becomes :
MyMethod(MyClass *this);

is the same scheme applied to globals on shared libraries?


does anyone know a good link for shared libraries under the hood?
i just couldnt find a site which explained the details.

>> ...methods...have the this pointer passed as first argument....is the same scheme applied to globals on shared libraries?
No. The compiler doesn't do anything like that. As I said, each module gets its own copy of global data. If it's a static library, then each module get its own copy of the code as well. If its a shared or dynamic library, then there is only one copy of the code, but each module still gets its own copy of global data.

In the case where there's only one copy of the code (ie. a shared library), then for each module using that library, the OS will typically load a module's copy of the library's global data at the same virtual address space in all modules. Then when the shared library's code is loaded into memory, all references to global data are "fixed up" to use the virtual address in which the data was loaded in each module. This way, when the library code is running within the context of a particular module, references to the libraries global data will auto-magically use that modules copy of that data.

For static libraries, the linker simply puts a copy of the code and data in each module that links with the library.

To understand the full end-to-end solution for an operating system, you'll need to understand:
- Executable file formats (PE for Windows, ELF for Linux, etc...)
- How your linker works.
- How the OS loads these files into memory.
- How the OS supports the concept of shared libraries (DLL's for Windows, Shared Objects for Linux)

gg

ah ok... its loaded into the same virtual address space for each process!
darn... its that simple...
thxalot