Hi Everybody,
My question is :
I have two process, named process1 and process 2 and both these process
communicate through shared memory.
In the process1 I have a buffer, whose pointer is there in the shared
memory,
My question is that: Is it possible for the Process2 to use this pointer in
the shared memory to access the content of the
buffer in the Process1.
Any help will be greatly appreciated.
Thx inadvance,
Mankan
Mankan <smankan@nospam.ueidaq.com> wrote:
Hi Everybody,
My question is :
I have two process, named process1 and process 2 and both these process
communicate through shared memory.In the process1 I have a buffer, whose pointer is there in the shared
memory,My question is that: Is it possible for the Process2 to use this pointer in
the shared memory to access the content of the
buffer in the Process1.Any help will be greatly appreciated.
No. The two processes will have different virtual addresses. (They may,
by coincidence have the same virtual addresses for the piece in
question, but that is not guaranteed).
Generally, shared memory is best done with offsets only, using the pointer
within each processes’ virtual address space.
I.e., in process1 and process2, you could have code like:
struct my_data_t *ptr;
ptr = mmap (…);
ptr → member [element]
You cannot have code like:
ptr → member → other_member
because the pointer “member” would need to contain a virtual address
that’s valid in both contexts – not gonna happen.
If that’s what you need to do (i.e., store two or more structures in the
shmem area), then you need to have two pointers:
struct my_data_1_t *p1;
struct my_data_2_t *p2;
p1 → member
p2 → other_member
would be a way of doing it…
Anyway, it’s a long, complicated topic 
Cheers,
-RK
–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.
Robert Krten <nospam84@parse.com> wrote:
No. The two processes will have different virtual addresses. (They may,
by coincidence have the same virtual addresses for the piece in
question, but that is not guaranteed).Generally, shared memory is best done with offsets only, using the pointer
within each processes’ virtual address space.I.e., in process1 and process2, you could have code like:
struct my_data_t *ptr;
ptr = mmap (…);
ptr → member [element]
You cannot have code like:
ptr → member → other_member
because the pointer “member” would need to contain a virtual address
that’s valid in both contexts – not gonna happen.If that’s what you need to do (i.e., store two or more structures in the
shmem area), then you need to have two pointers:struct my_data_1_t *p1;
struct my_data_2_t *p2;p1 → member
p2 → other_memberwould be a way of doing it…
Anyway, it’s a long, complicated topic >
Maybe long and complicated, but very important. No one should even
consider using shared memory between two processes unless they
understand this. In fact, I’m not so sure that it’s that long and
complicated. I think you presented it quite well.
However, there should be a well written document posted on the subject
somewhere.
–
Bill Caroselli – Q-TPS Consulting
1-(626) 824-7983
qtps@earthlink.net
“Robert Krten” <nospam84@parse.com> wrote in message
news:b20j13$b58$1@inn.qnx.com…
Mankan <> smankan@nospam.ueidaq.com> > wrote:
Hi Everybody,No. The two processes will have different virtual addresses. (They may,
by coincidence have the same virtual addresses for the piece in
question, but that is not guaranteed).
Well, technically you could do this by using the MAP_FIXED option
with mmap and specifying the address where the block is to be mapped
into memory. As long as you used the same address in both processes
then pointers within the shared memory block could point at other objects
in the shared memory block.
Generally, shared memory is best done with offsets only, using the pointer
within each processes’ virtual address space.
This is certainly true. The possibility I presented would be incredibly
hard to
maintain (not to mention, you’ve got to deal with the fact that the call to
mmap
could fail if the address range was already in use).
Randy Hyde
Randall Hyde <randall.nospam.hyde@ustraffic.net> wrote:
“Robert Krten” <> nospam84@parse.com> > wrote in message
news:b20j13$b58$> 1@inn.qnx.com> …
Mankan <> smankan@nospam.ueidaq.com> > wrote:
Well, technically you could do this by using the MAP_FIXED option
with mmap and specifying the address where the block is to be mapped
into memory. As long as you used the same address in both processes
then pointers within the shared memory block could point at other objects
in the shared memory block.Generally, shared memory is best done with offsets only, using the pointer
within each processes’ virtual address space.This is certainly true. The possibility I presented would be incredibly
hard to
maintain (not to mention, you’ve got to deal with the fact that the call to
mmap
could fail if the address range was already in use).
Or, even worse, it could succeed… 
Randall Hyde <randall.nospam.hyde@ustraffic.net> wrote in message
news:b20un5$nr9$1@inn.qnx.com…
Well, technically you could do this by using the MAP_FIXED option
with mmap and specifying the address where the block is to be mapped
into memory. As long as you used the same address in both processes
then pointers within the shared memory block could point at other objects
in the shared memory block.
You can’t assume you could mmap(…MAP_FIXED…), even if nothing else is
mapped into that vmem region. There can be other platform dependant
restrictions over where mapping can take place, forcing us to cause a
failure.
This is certainly true. The possibility I presented would be incredibly
hard to
maintain (not to mention, you’ve got to deal with the fact that the call
to
mmap
could fail if the address range was already in use).
And not portable from version to version or architecture to architecture.
-Adam
“Adam Mallory” <amallory@qnx.com> wrote in message
news:b2153e$l7f$1@nntp.qnx.com…
And not portable from version to version or architecture to architecture.
If mmap returns success, how would this fail when porting the code from
architecture to architecture? For that matter, from version to version?
If QNX returns success on the mmap call and the OS has indeed mapped
the structure into the shared reason, why on earth would pointers appearing
within that region not successfully point at other objects within that
region?
Clearly if QNX returns failure on mmap, there are problems. And this means
that
the software wouldn’t be able to function. But if it returns success and
you’re
claiming it would still fail, then there are problems with the OS.
If you’re simply suggesting that setting a fixed address wouldn’t be
portable,
I believe I pretty much covered this by claiming the code would be
incredibly
hard to maintain.
Randy Hyde
“Bill Caroselli” <qtps@earthlink.net> wrote in message
news:b20qml$jhi$1@inn.qnx.com…
Robert Krten <> nospam84@parse.com> > wrote:
No. The two processes will have different virtual addresses. (They
may,
by coincidence have the same virtual addresses for the piece in
question, but that is not guaranteed).Generally, shared memory is best done with offsets only, using the
pointer
within each processes’ virtual address space.I.e., in process1 and process2, you could have code like:
struct my_data_t *ptr;
ptr = mmap (…);
ptr → member [element]
You cannot have code like:
ptr → member → other_member
because the pointer “member” would need to contain a virtual address
that’s valid in both contexts – not gonna happen.If that’s what you need to do (i.e., store two or more structures in the
shmem area), then you need to have two pointers:struct my_data_1_t *p1;
struct my_data_2_t *p2;p1 → member
p2 → other_memberwould be a way of doing it…
Anyway, it’s a long, complicated topic >
Maybe long and complicated, but very important. No one should even
consider using shared memory between two processes unless they
understand this. In fact, I’m not so sure that it’s that long and
complicated. I think you presented it quite well.However, there should be a well written document posted on the subject
somewhere.
this ? http://www.opengroup.org/onlinepubs/007904975/toc.htm
// wbr
Randall Hyde <randall.nospam.hyde@ustraffic.net> wrote in message
news:b219p1$67f$1@inn.qnx.com…
If mmap returns success, how would this fail when porting the code from
architecture to architecture? For that matter, from version to version?
If QNX returns success on the mmap call and the OS has indeed mapped
the structure into the shared reason, why on earth would pointers
appearing
within that region not successfully point at other objects within that
region?
That’s not at all what I said. I said that even if nothing is mapped in the
vaddr range you specify, we’re still able to fail the call.
Clearly if QNX returns failure on mmap, there are problems. And this
means
that
the software wouldn’t be able to function. But if it returns success and
you’re
claiming it would still fail, then there are problems with the OS.
Obviously, if we fail the mmap() call ‘there are problems’. I was merely
saying that sometimes there are achitecture related constraints against
mapping in certain vaddr areas at certain times.
-Adam