Hi All,
I am new to linux. I have a doubt. Here is my question:
I have a class named "shrd" like this:
class shrd
{
public:
static int i;
};

I have it in a dynamic library.
I load the library from two process A and B. If I change the variable
in process A, will it be visible in process B? I tried this in windows
and its not the case. But one of my friend working on linux tells that
it happens in Linux. If it happens like this my question is, why is
there a need for shared memory? or inter process communication? Please
let me know, and also let me know where I can read in details about
the linux kernel and its features (books or articles)
~Thanks
Dexter

DXT-KID wrote:
> Hi All,
> I am new to linux. I have a doubt. Here is my question:
> I have a class named "shrd" like this:
> class shrd
> {
> public:
> static int i;
> };
> 
> I have it in a dynamic library.
> I load the library from two process A and B. If I change the variable
> in process A, will it be visible in process B? I tried this in windows
> and its not the case. But one of my friend working on linux tells that
> it happens in Linux. If it happens like this my question is, why is
> there a need for shared memory? or inter process communication? 

I cant answer as to whether it works that way or not, but I can hint at 
the answer to the other questions.

If two programs invoke a single object, like your shared DLL, then its 
reasonable that that library can maintain common variables to both.

The need for shared memory is when you don't have a single object 
controlling access to a piece of memory  and the need for interprocess 
communication is similar. Except of course the shared memory access 
mechanism becomes that common piece of code..

In a sense these are all fancy terms for different ways to achieve what 
amounts to  the same thing: getting more or less autonomous threads to 
behave *less* autonomously!

There is no other way to actually communicate between processes than a 
it of shared memory at some level or other, even if that memory is made 
to look like a comms channel, a disk drive, a semaphore system or whatever.

At heart, unless you have a true comms channel formed of a piece of wire 
with protocol on it, all methods are shared memory. The difference is 
how you form a high level abstraction out of that.

Once upon a time before computer scientists muddied the water, we used 
to just write this stuff in assembler, but that was too hard for the 
poor old CompScis, they could only deal with abstract models, so they 
dreamt them up and passed it to coders to make their weird , overhead 
laden abstractions work. So we now have object oriented programming etc...




Please
> let me know, and also let me know where I can read in details about
> the linux kernel and its features (books or articles)
> ~Thanks
> Dexter

Pass.

Try Knuth, the father of all obfuscation.

* DXT-KID <dexter.mishra@gmail.com>:
> I have a class named "shrd" like this:
> class shrd
> {
> public:
> static int i;
> };
> 
> I have it in a dynamic library.
> I load the library from two process A and B. If I change the variable
> in process A, will it be visible in process B?

Definitely no. This would break a LOT of code (just think about the std
c lib "errno" variable).

Basically, most dynamic linkers on systems with an MMU map the text
segment of a shared library to a shared page (read only), but the
data/bss segments are mapped individually for each address space.

(Of course, the variable will always be shared across threads, because
they share the same address space)

Regards, Felix

-- 
 Felix Palmen       (Zirias)  + [PGP] Felix Palmen <felix@palmen-it.de>
 web:   http://palmen-it.de/  |             http://palmen-it.de/pub.txt
 my open source projects:     |   Fingerprint: ED9B 62D0 BE39 32F9 2488
 http://palmen-it.de/?pg=pro  +                5D0C 8177 9D80 5ECF F683

On Sep 7, 5:17=A0pm, fe...@palmen-it.de (Felix Palmen) wrote:
> * DXT-KID <dexter.mis...@gmail.com>:
>
> > I have a class named "shrd" like this:
> > class shrd
> > {
> > public:
> > static int i;
> > };
>
> > I have it in a dynamic library.
> > I load the library from two process A and B. If I change the variable
> > in process A, will it be visible in process B?
>
> Definitely no. This would break a LOT of code (just think about the std
> c lib "errno" variable).
>
> Basically, most dynamic linkers on systems with an MMU map the text
> segment of a shared library to a shared page (read only), but the
> data/bss segments are mapped individually for each address space.
>
> (Of course, the variable will always be shared across threads, because
> they share the same address space)
>
> Regards, Felix
>
> --
> =A0Felix Palmen =A0 =A0 =A0 (Zirias) =A0+ [PGP] Felix Palmen <fe...@palme=
n-it.de>
> =A0web: =A0http://palmen-it.de/=A0| =A0 =A0 =A0 =A0 =A0 =A0http://palmen-=
it.de/pub.txt
> =A0my open source projects: =A0 =A0 | =A0 Fingerprint: ED9B 62D0 BE39 32F=
9 2488
> =A0http://palmen-it.de/?pg=3Dpro=A0+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A05D0C =
8177 9D80 5ECF F683

That is what tried to convince, he is not believing. So I want to give
him some solid proof. If any one know about some detail reads about
the loader management in linux, like how the lib-linux.so works please
do send it.

DXT-KID <dexter.mishra@gmail.com> writes:

> That is what tried to convince, he is not believing. So I want to give
> him some solid proof. If any one know about some detail reads about
> the loader management in linux, like how the lib-linux.so works please
> do send it.

Just demonstrate to him how it actually works with a small shared
library and two programs.

Or stop caring what he thinks.

-- 
http://www.greenend.org.uk/rjk/

On Sep 7, 11:23=A0pm, Richard Kettlewell <r...@greenend.org.uk> wrote:
> DXT-KID <dexter.mis...@gmail.com> writes:
> > That is what tried to convince, he is not believing. So I want to give
> > him some solid proof. If any one know about some detail reads about
> > the loader management in linux, like how the lib-linux.so works please
> > do send it.
>
> Just demonstrate to him how it actually works with a small shared
> library and two programs.
>
> Or stop caring what he thinks.
>
> --http://www.greenend.org.uk/rjk/

Well yes I did it, but its just interesting to find out about the
details of loader behaviuour in linux. So if some one has some good
links please share.

On 9.9.10 9:25 , DXT-KID wrote:
> On Sep 7, 11:23 pm, Richard Kettlewell<r...@greenend.org.uk>  wrote:
>> DXT-KID<dexter.mis...@gmail.com>  writes:
>>> That is what tried to convince, he is not believing. So I want to give
>>> him some solid proof. If any one know about some detail reads about
>>> the loader management in linux, like how the lib-linux.so works please
>>> do send it.
>>
>> Just demonstrate to him how it actually works with a small shared
>> library and two programs.
>>
>> Or stop caring what he thinks.
>>
>> --http://www.greenend.org.uk/rjk/
>
> Well yes I did it, but its just interesting to find out about the
> details of loader behaviuour in linux. So if some one has some good
> links please share.

It is not a loader item. It is in the core part of the
kernel process and memory management.

Please do not start many threads of the same question
on the same or different groups: it confuses the
discussion unnecessarily. If you are not happy with
the responses, say it and tell why.

-- 

Tauno Voipio
tauno voipio (at) iki fi

DXT-KID <dexter.mishra@gmail.com> writes:
> On Sep 7, 11:23 pm, Richard Kettlewell <r...@greenend.org.uk> wrote:
>> DXT-KID <dexter.mis...@gmail.com> writes:

>>> That is what tried to convince, he is not believing. So I want to give
>>> him some solid proof. If any one know about some detail reads about
>>> the loader management in linux, like how the lib-linux.so works please
>>> do send it.
>>
>> Just demonstrate to him how it actually works with a small shared
>> library and two programs.
>>
>> Or stop caring what he thinks.
>
> Well yes I did it, but its just interesting to find out about the
> details of loader behaviuour in linux. So if some one has some good
> links please share.

I suggest starting with the man pages for ld-linux.so and mmap, and
continuing to glibc and the kernel source if you want to know
implementation details.

-- 
http://www.greenend.org.uk/rjk/