Ok, my question is how exactly is shared memory supposed to behave as
specified by the POSIX standard. If I have two processes that both use
shm_open and mmap on the same memory:
 1) If one process writes to the mapped portion of the file, how soon
are the changes affecting the second process ? Is a flushing operation
required for this ?
 2) How efficient is it ? Is the changes to memory being written first
to file by the first process then read from file by second process
(inefficient) or is the RAM really being shared without necessarily
involving disk operations ? Or is it a combination of the two ...
 3) How much more efficient is using shared memory over using
non-buffered IO ?
I would appreciate it if anyone could suppy some answers to these
questions,

Zaphod

zaphodthefirst@hotmail.com (zaphod) writes:

> Ok, my question is how exactly is shared memory supposed to behave as
> specified by the POSIX standard. If I have two processes that both use
> shm_open and mmap on the same memory:
>  1) If one process writes to the mapped portion of the file, how soon
> are the changes affecting the second process ? Is a flushing operation
> required for this ?

On a single-processor system the change is visible immediately.
On multiprocessors with "relaxed" memory models a cache-flush
operation may be required.

>  2) How efficient is it ? Is the changes to memory being written first
> to file by the first process then read from file by second process
> (inefficient) or is the RAM really being shared without necessarily
> involving disk operations ? Or is it a combination of the two ...

The same physical page frame in RAM is really being shared.

>  3) How much more efficient is using shared memory over using
> non-buffered IO ?

Much more efficient, since no context switches are required to
transfer data. It is probably safe to say that transferring a single
word via shared memory is at least 10 times (and probably at least
a 100 times) more efficient, than doing it via IO.

Cheers,
-- 
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

On Thu, 27 Nov 2003 22:23:02 -0800, Paul Pluzhnikov wrote:

> zaphodthefirst@hotmail.com (zaphod) writes:
> 
>> Ok, my question is how exactly is shared memory supposed to behave as
>> specified by the POSIX standard. If I have two processes that both use
>> shm_open and mmap on the same memory:
>>  1) If one process writes to the mapped portion of the file, how soon
>> are the changes affecting the second process ? Is a flushing operation
>> required for this ?
> 
> On a single-processor system the change is visible immediately.
> On multiprocessors with "relaxed" memory models a cache-flush
> operation may be required.

 If you want to see the information in the other process you'll need to
always to this (you might do it implicitly via. a locking scheme).

>>  3) How much more efficient is using shared memory over using
>> non-buffered IO ?
> 
> Much more efficient, since no context switches are required to
> transfer data. It is probably safe to say that transferring a single
> word via shared memory is at least 10 times (and probably at least
> a 100 times) more efficient, than doing it via IO.

 This is not true. Shared memory requires just as much "context
switches" although it might not require going into and out of the kernel
for each transaction. Shared memory requires some kind of external
synchronization which can be expensive, also the memory barrier requires a
cache synronization ... if not a cache flush.
 For sharing/transfering _large_ amounts of data in a single transaction
mmaping shared memory can be a win. For transfering less than a page of
data I can't see it being faster[1] and it's much more complicated.

[1] It might be possible to make mmap faster but have it randomly corrupt
the data every now and again.

-- 
James Antill -- james@and.org
Need an efficient and powerful string library for C?
http://www.and.org/vstr/

James Antill <james-netnews@and.org> writes:

>  If you want to see the information in the other process you'll need to
> always to this (you might do it implicitly via. a locking scheme).

On a single-CPU machine?
Could you elaborate?

> >>  3) How much more efficient is using shared memory over using
> >> non-buffered IO ?
> > 
> > Much more efficient, since no context switches are required to

I should have said "Much more efficient under ceratain conditions ..."

>  This is not true. Shared memory requires just as much "context
> switches" although it might not require going into and out of the kernel
> for each transaction. 

I can construct a scenatio where your statement is true.
I can construct another scenario where your statement is absolutely false.

Cheers,
-- 
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.