New subject: [linux-audio-dev] Re: Shared memory

15 Jul 2003

...
 From: Ingo Oeser
&lt;ingo.oeser(a)informatik.tu-chemnitz.de&gt;

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

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