How does a shared library work?

[Eldridge, Michael]

> On 10/26/05, janne <jan.moren at lucs.lu.se> wrote:
> > ons 2005-10-26 klockan 10:18 +0200 skrev Tshepang Lekhonkhobe:
> > > Hello,
> > > I wanted to avoid some searching headache by asking this question here:
> > > I hear that the advantage of shared libraries is that there's only one
> > > copy of that library in memory and I assume that the library is loaded
> > > in memory only the first moment that a dependant package is run. But
> > > who's reponsible for making sure whose turn it is to use that library
> > > in case of several dependant packages requiring its use? Is it the
> > > kernel?
> >
> > Neither. When you write something to be used as a shared library, it
> > needs to be written to be "reentrant". That means the library must be
> > able to have more than one process use it - even use the same exact code
> > - at the same time. That is not as big a headache as it sounds.

it's not a headache at all.  the data segment is going to be completely
independent.  just because the text segment maps to the same instructions
doesn't mean that you can't change the value of global variables.

reentrance is typically only a concern nowadays in multithreaded development.

> > Remember that the code itself is never actually changed; it is in effect
> > a fixed text run by the processes (the same is true of just about any
> > code in fact). The problem is variables that do change, but that is
> > neatly solved by the memory controller:
> >
> > Every process has its own mapped memory. This memory is divided into
> > text segments (the actual code) and data segments (room for variables,
> > stack and other data that changes as you run the application). When you
> > use the shared library, its code is mapped into the processes memory.
> > Note that it's not copied - there's still only one "real" copy - but the
> > memory controller effectively makes it seem it's part of the rest of the
> > program code.

the stack segment is separate from the data segment.

> Is the memory controller a part of the kernel?

no.  see here: http://en.wikipedia.org/wiki/Memory_management_unit

-mike