[linux-audio-dev] Re: Shared memory

[Juhana Sadeharju]

>From: Ingo Oeser <ingo.oeser at informatik.tu-chemnitz.de>
>
>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.

No, my test indicates that the memory is not *the same* in the two
processes. If "shared memory" is something which is the same only
occasionally, then that is what I have now.

Semaphores or atomic operations has nothing to do with this problem.

>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.

That is better explanation for the slow printing. The shmserver
may be too intensive. However, it is not an explanation for
why the shared memory is not *the same*.

But then, while shmserver was running and shmclient printing,
my simple painting program indicated no slowdowns in painting,
which involves a large brush with computations like sqrt() on
each pixel.

I remember this same problem appeared when I modified XWave
at 1998. The play process (X toolkits background process) wrote
the play line location and the GUI process read the location.
Now that did not involve any unlimited computations as the
processes were bound to D/A converter and to periodic update
of X toolkit.

>> 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.

I don't understand. Can you explain how semaphores are used for that?

Best regards,

Juhana