I have created a shared memory  (system V) (using shmget,shmat) of 200
MB. There is one writer process which populates the shared memory
region.

There is another reader process which has to read this data. I need to
read the entire data in minimum time.

In the first approach the reader locks the shared memory and reads the
data from the shared memory, but it takes a lot of time.

So the second approach would be to create a replica of this shared
memory block, and my reader process would then read from the replica.

Please could you suggest some way of making a replica of the existing
shared memory.

[ Post a follow-up to this message ]

On May 16, 11:35 pm, hoze...@gmail.com wrote:
> I have created a shared memory  (system V) (using shmget,shmat) of 200
> MB. There is one writer process which populates the shared memory
> region.
>
> There is another reader process which has to read this data. I need to
> read the entire data in minimum time.
>
> In the first approach the reader locks the shared memory and reads the
> data from the shared memory, but it takes a lot of time.
>
> So the second approach would be to create a replica of this shared
> memory block, and my reader process would then read from the replica.
>
> Please could you suggest some way of making a replica of the existing
> shared memory.

I can't think of any generic way to do it. I can think of quite a few
tricks that might work depending on the specifics of your situation.

For example, if the writer always writes out the entire data set, you
could just have the writer write to another chunk of memory. That way,
the reader's lock could be omitted and the writer wouldn't have to
wait for the reader to finish.

DS

[ Post a follow-up to this message ]

hozefap@gmail.com wrote:
> I have created a shared memory  (system V) (using shmget,shmat) of 200
> MB. There is one writer process which populates the shared memory
> region.
>
> There is another reader process which has to read this data. I need to
> read the entire data in minimum time.
>
> In the first approach the reader locks the shared memory and reads the
> data from the shared memory, but it takes a lot of time.
>
> So the second approach would be to create a replica of this shared
> memory block, and my reader process would then read from the replica.
>
> Please could you suggest some way of making a replica of the existing
> shared memory.

You're getting ahead of yourself. First thing that this question brings to
mind is some sort of multi-version concurrency control for virtual memory.
Which would be sweet, but not too common, AFAIK, or at least not in any
manner or kind easily leveraged by an application.

You might want to follow up w/ some more specifics, but here's a couple of
suggestions:

1) Setup barriers (i.e. POSIX barriers, or just plain mutexes). You can
setup two barriers, one which coincides with byte #0 and one with byte 100 *
(1 << 20). When the writer finishes writing the first 100 megabytes, it
opens the first barrier, which the reader was waiting on. The reader than
processes the first chunk, and then waits on the second barrier. When the
writer finishes with the second chunk, it again signals on the second
barrier, allowing the reader to finish. You could get more fine-grained than
this, tuning and analyzing as you go. Though, this might be a horrible idea,
and I've never tried it.

2) Don't use shared memory, employ a FIFO construct with mkfifo(3). The
writer simply writes the FIFO, the reader reads, and everything is
implicitly synchronized. On Linux 2.6 you can use splice(2) and vmsplice(2)
to effectively make this zero-copy.

3) What David Schwartz said, which IIRC was something akin to #2, i.e. use
multiple buffers and a queue construct.

[ Post a follow-up to this message ]

On May 17, 12:17 pm, William Ahern <will...@wilbur.25thandClement.com>
wrote:
> hoze...@gmail.com wrote:

> 3) What David Schwartz said, which IIRC was something akin to #2, i.e. use
> multiple buffers and a queue construct.

Actually, on re-reading my post, it's really hard to understand what I
was saying. But you got it right. The idea is to have the reader read
from one place while the writer writes to the next place. That way,
the reader does not block the writer. I wasn't necessarily speaking
about a queue, but that would certainly be one way to do it, and
probably the easiest to grasp conceptually.

Think of it as two people communicating in writing. I can write on a
piece of paper, then give it to you, but I can't write anything until
you give me back the paper. So I can't write the next thing while you
are reading. Simply using two pieces of paper that can handed back and
forth would solve this. (Assuming that all or most of the data changes
or needs to be rewritten anyway. If just a few bytes do, then queuing
deltas might be better.)

DS

[ Post a follow-up to this message ]

On 17 May 2007 16:29:44 -0700 David Schwartz <davids@webmaster.com> wrote:

| On May 17, 12:17 pm, William Ahern <will...@wilbur.25thandClement.com>
| wrote:
|> hoze...@gmail.com wrote:
|
|> 3) What David Schwartz said, which IIRC was something akin to #2, i.e. us
e
|> multiple buffers and a queue construct.
|
| Actually, on re-reading my post, it's really hard to understand what I
| was saying. But you got it right. The idea is to have the reader read
| from one place while the writer writes to the next place. That way,
| the reader does not block the writer. I wasn't necessarily speaking
| about a queue, but that would certainly be one way to do it, and
| probably the easiest to grasp conceptually.
|
| Think of it as two people communicating in writing. I can write on a
| piece of paper, then give it to you, but I can't write anything until
| you give me back the paper. So I can't write the next thing while you
| are reading. Simply using two pieces of paper that can handed back and
| forth would solve this. (Assuming that all or most of the data changes
| or needs to be rewritten anyway. If just a few bytes do, then queuing
| deltas might be better.)

A little more elaborate is my virtual ring buffer.  Transposing VRB to
the paper analogy would be like two people working on a paper roll that
is cycling between them continuously.  One writes, the other reads.  The
writer erases what is already there, too.

VRB works by having a chunk of memory a multiple of page size, and mapping
it into memory twice adjacently.  It then operates much like a normal ring
buffer that wraps around.  But for pointers near the end, you don't have
to worry about making operations that access the data wrap around as they
just extend into the mirror image.

Libre code at http://vrb.slashusr.org/

--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org)  /  Do not send to the address below |
| first name lower case at ipal.net   /  spamtrap-2007-05-18-1614@ipal.net |
|------------------------------------/-------------------------------------|

[ Post a follow-up to this message ]