[linux-audio-dev] Re: Shared memory

[Ingo Oeser]

Hi Juhana,

On Sat, Jul 12, 2003 at 10:32:54PM +0300, Juhana Sadeharju wrote:
> Hello. I examined further the shared memory malfunction.
> Locking the memory with mlockall() did not help: the shared
> memory is not updated in the client. I used mlockall() both in
> shmserver and in shmclient.
> 
> For some reason the shared memory is not a true shared memory.
> The shmserver and shmclient do have the shared memory segment
> obtained with the same shmid value, but processes seems to
> have their own duplicates of it. I have no other explanation.
 
What does /proc/$pid/maps show? For both: server and client.

On my machine it looks like this:

Client:
40014000-40018000 rw-s 00000000 00:04 32669704   /SYSV00000000 (deleted)
Server:
40015000-40019000 rw-s 00000000 00:04 32669704   /SYSV00000000 (deleted)

> These duplicates were updated when the shmclient performed sleep(1).

Which is a syscall and forces all kinds of flushing, because it
will context switch for this second. 

> Now I have non-waiting sched_yield() in the shmclient, and that helps.

Same here.

> shmserver is very computation intensive process: it goes through
> the whole shared memory and increases the integers there. First
> there are 250000 zeros, then 250000 ones, and so on. The client
> reads only the first memory location in a loop, and prints out the
> value if that value is not yet printed.
 
> What practically happens is that shmserver has enough time to
> increase the values multiple times before shmclient gets its
> turn to check the values. shmclient does not print values such
> as 1234, 1235, 1236 --- the scheduling period is too long for
> that. In fact, the shmclient prints the values surprisingly
> slow; maybe 20 times per second at maximum.

You have synchronisation problems. Shared memory means only that
it's shared, not that it's synchronized for you. You either need
to synchronize portably by hand using semaphores or use atomic
operations.

Or you have scheduling problems, if you are disturbed by the
fact, that the client isn't getting the same amount of CPU as the
server.

> Without "renice 19" the shmclient prints values in steps of 24 (avg),
> and with "renice 19" the shmclient prints values in steps of 2 (avg).
> Maybe 20 times per second with "renice 19". Slow.

That's normal. They lock each other out for a whole timeslice,
since they are CPU-bound. If you want them to schedule at certain
events (e.g. after one of these computation cycles), you have to
tell the kernel by using semaphores.

> What this could mean? When an audio software does non-realtime
> background computations, the other non-realtime processes could be
> in trouble even if they run at different user priorities.

Yes, that's true. If you use up more CPU then you machine has,
you are always in trouble. Try to compute smaller chunks and give
the CPU away by doing other work. 

Multiple threads/processes do only make sense, if you have spare
CPU cycles. If you don't have spare CPU cycles, then your system
is simply underpowered for that task. If your system load is spiky,
then your buffer design is broken.

> Question: does the same "shared memory" problem occur with threads?
> Intuitively there should not be problems, but never know after what
> I have seen.

I think the problem is misunderstanding, what shared memory does.

Regards

Ingo Oeser