copying structures in shared memory

A

Aditya

Hi All,

I would like to know the comparision between two approaches for
copying data in shared memory.

1.) contigous memory chuks in a structure

2.) pointers referneced in structures.

Example

typedef struct
{
int x
int y

} struct_b

Case b
typedef struct
{
struct_b * b
} struct_a

Case a
typedef struct
{
struct_b b
} struct_a
 
J

Jens Thoms Toerring

Aditya said:
I would like to know the comparision between two approaches for
copying data in shared memory.
1.) contigous memory chuks in a structure
2.) pointers referneced in structures.

typedef struct
{
int x
int y
} struct_b
Case a
typedef struct
{
struct_b b
} struct_a
Case b
typedef struct
{
struct_b * b
} struct_a

In one respect this is bit of a borderline question topically-
wise since the term "shared memory" only makes sense when there
are two or more processes running at the same time and C as a
language doesn't makes any promises about that. But anyway...

If I understand your question correctly you have some doubts
if "Case b" is in principle the same as (or even preferable
to) "Case a" or if there are some pitfalls when using one or
the other. They definitely are different.

We have to get one thing clear to start with: if you have two
processes using a different address space (like it's the rule
in most modern operating systems - and otherwise you wouldn't
have to use "shared memory") then a pointer makes only sense
in the process this pointer is coming from. Thus in process 1
a pointer with a certain value may point to an important data
structure, but in process 2 the same address may not even be
accessible.

Thus when you have a structure that is shared between two pro-
cesses it should not contain pointers that only make sense in
one of the processes. This rules out using your "Case b" since
if structure 'b' was defined in process 1 a pointer to 'b' has
no meaning at all in process 2. That's because then struct 'b'
the pointer is pointing to is residing somewhere in the address
space of process 1 - but which process 2 can't access.

If you want to share data between two processes all the data
must reside in shared memory, not just pointers. Thus your
"Case b" would only work if structure 'b' resides also in
shared memory - and then only if your system would make sure
somehow that the shared memory is mapped to the same addresses
in both processes!).

Thus, unless you're doing something "very clever" (and very
system-dependent as well) then your "Case a" is the only way
to go. Put all data into shared memory and don't use pointers.

And also don't forget that there are further issues to be
considered. A structure you copied to shared memory may not
be properly aligned for the "normal" way to access members
of it. If you e.g. have (with "Case a") a variable named 'A'
of type 'struct_a *', pointing to a structure in shared me-
mory a simple access like

x = A->b.x ;

may result in your program crashing on some architectures
(while seemingly working perfectly fine on others...) You
may have to resort to coping members out of the structure
in shared memory using memcpy() before using their values.

Regards, Jens
 
A

Aditya

In one respect this is bit of a borderline question topically-
wise since the term "shared memory" only makes sense when there
are two or more processes running at the same time and C as a
language doesn't makes any promises about that. But anyway...

If I understand your question correctly you have some doubts
if "Case b" is in principle the same as (or even preferable
to) "Case a" or if there are some pitfalls when using one or
the other. They definitely are different.

We have to get one thing clear to start with: if you have two
processes using a different address space (like it's the rule
in most modern operating systems - and otherwise you wouldn't
have to use "shared memory") then a pointer makes only sense
in the process this pointer is coming from. Thus in process 1
a pointer with a certain value may point to an important data
structure, but in process 2 the same address may not even be
accessible.

Thus when you have a structure that is shared between two pro-
cesses it should not contain pointers that only make sense in
one of the processes. This rules out using your "Case b" since
if structure 'b' was defined in process 1 a pointer to 'b' has
no meaning at all in process 2. That's because then struct 'b'
the pointer is pointing to is residing somewhere in the address
space of process 1 - but which process 2 can't access.

If you want to share data between two processes all the data
must reside in shared memory, not just pointers. Thus your
"Case b" would only work if structure 'b' resides also in
shared memory - and then only if your system would make sure
somehow that the shared memory is mapped to the same addresses
in both processes!).

Thus, unless you're doing something "very clever" (and very
system-dependent as well) then your "Case a" is the only way
to go. Put all data into shared memory and don't use pointers.

And also don't forget that there are further issues to be
considered. A structure you copied to shared memory may not
be properly aligned for the "normal" way to access members
of it. If you e.g. have (with "Case a") a variable named 'A'
of type 'struct_a *', pointing to a structure in shared me-
mory a simple access like

x = A->b.x ;

may result in your program crashing on some architectures
(while seemingly working perfectly fine on others...) You
may have to resort to coping members out of the structure
in shared memory using memcpy() before using their values.

                            Regards, Jens
--
  \   Jens Thoms Toerring  ___      (e-mail address removed)
   \__________________________      http://toerring.de- Hide quoted text -

- Show quoted text -

thanks...my doubts are cleared..

it really helped me
 
C

Chris M. Thomasson

Jens Thoms Toerring said:
Aditya said:
I would like to know the comparision between two approaches for
copying data in shared memory.
1.) contigous memory chuks in a structure
2.) pointers referneced in structures.

typedef struct
{
int x
int y
} struct_b
Case a
typedef struct
{
struct_b b
} struct_a
Case b
typedef struct
{
struct_b * b
} struct_a

In one respect this is bit of a borderline question topically-
wise since the term "shared memory" only makes sense when there
are two or more processes running at the same time and C as a
language doesn't makes any promises about that. But anyway...

If I understand your question correctly you have some doubts
if "Case b" is in principle the same as (or even preferable
to) "Case a" or if there are some pitfalls when using one or
the other. They definitely are different.

We have to get one thing clear to start with: if you have two
processes using a different address space (like it's the rule
in most modern operating systems - and otherwise you wouldn't
have to use "shared memory") then a pointer makes only sense
in the process this pointer is coming from. Thus in process 1
a pointer with a certain value may point to an important data
structure, but in process 2 the same address may not even be
accessible.
[...]

Right. You can do linked lists in shared memory, however you need to use
offsets from the base memory of the executing process instead of pointers in
order for everything to work correctly. Something like this, modulo
synchronization of course:


static unsigned char* g_my_shm_base = [...];


struct shm_ptr {
size_t offset;
};


#define SHM_PTR(b, p) ((void*)( \
(b) + (p)->offset \
))




struct node {
struct shm_ptr shm_next;
};


void iterate(shm_ptr* shm_head) {
struct node* cur = SHM_PTR(g_my_shm_base, shm_head);
while (cur) {
struct node* next = SHM_PTR(g_my_shm_base, &cur->shm_next);
[...];
head = cur;
}
};




The offsets work in any process mapping a common view of the shm no matter
where the address is.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,582
Members
45,066
Latest member
VytoKetoReviews

Latest Threads

Top