Re: [linux-audio-dev] Shared memory? - Linux-audio-dev

7 Jul 2003

Could anyone check the shmserver.tar.gz, compile it, and test
if you have the same problem? Additional instructions below.

I have though about why the shared memory freezes. It could be
that Linux copies the shared memory pages for each client:
one shared memory segment, multiple copies. Would locking
the memory help? Maybe, maybe not.

I know there are high performance applications using the shared
memory well (at least their authors may think so). But so does
my own alsashmrec works well too (so I thought). If there indeed
is a severe (a minor?) problem in the kernel, then in all these
application it may cause very short freezes (until read, write,
sleep, suspend, etc. call releases it). A jitter in updating
lock-free FIFOs on shared memory.

If you don't get it or otherwise cannot find out what is going on,
then where I should post this? Is there a list where the kernel
and shared memory experts are reading?

And hey, why shmget did not work? See shmalloc_named_get().

Best regards,

Juhana

Additional instructions and the previous mail.

1. Compile it without sleep(1) [ as in code below ] and without
fprintf with ggg's [ one could change that to "g" so that
screen does not go too fast ].
Then compile and test with sleep, and then test with fprintf with
"g".

2. First run shmserver in a terminal. Copy the mid value
(second value printed).

3. Then run shmclient in another terminal. Paste the mid value:
 % shmclient <midvalue>

...
 From: Juhana Sadeharju &lt;kouhia(a)nic.funet.fi&gt;
To: linux-audio-dev(a)music.columbia.edu
Subject: 
Date: 	Fri, 4 Jul 2003 16:46:25 +0300
Reply-To: linux-audio-dev(a)music.columbia.edu

 From: Ralfs Kurmis &lt;kurmisk(a)inbox.lv&gt;

Try out this example
Split it in seperate files
( Needs x ) 
Hello. Thanks for the example, but I see some problems there:
if the second process does not find the segment given by the key,
you example makes two distinct segments. That is what happen with
me. Because I don't have IPC_CREAT in the second process, my
program simply fails instead of creating second segment.

I got it working otherway, but there are severe problems.
In client, I simply skipped the shmget() and queried
immediately the segment with shmat() with the mid value
printed by the server.

The example mailed here used shmget() with IPC_CREAT.
When I used IPC_CREAT for both server and client, as I expected,
I got two separate shared memories. In fact, as I make the shared
memory in shmserver which is run first, the shmclient should not use
IPC_CREAT at all.

It works, but while the server seems to fill the shared memory
with increasing integer numbers, the client behaves strangely.
I have this code in shmclient now:

  k = -1;
  for (;;) {
    if (k != nums[1]) {
      k = nums[1];
      fprintf(stderr,"%i\n",k);
    }
    // sleep(1);
    // fprintf(stderr,"ggggg\n");
  }

What should it do? It should ideally print the increasing numbers:
5435, 5436, 5437, etc. With sleep(1) it prints a new value once per
second. However, without sleep(1), it prints only one number and then
does not print anything anymore. It looks like Linux does not update
the shared memory, why?

When the "ggggg" is printed (without sleep), the shmclient prints only
one number and repeatedly the "ggggg". Why the shared memory is not
updated in this? I remember I had a similar problem with old XWave
software at 1998 with much earlier kernel version (now I have 2.4.18 of
RedHat 7.3).

This looks serious problem. It may be that nobody has noticed
it because either one uses sleep() or read()/write() in an
audio system. That is, your software may work, but the problem
may degrage the performance (as it certainly did freeze the
printing in my shmclient). Perhaps the problem may cause an audio
engine never work as fully as possible.

If you get the shmclient work while the sleep(1) is commented out,
please let me know :-)

http://www.funet.fi/~kouhia/shmserver.tar.gz 