12 Jul
2003
12 Jul
'03
5:46 p.m.
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.
These duplicates were updated when the shmclient performed sleep(1).
Now I have non-waiting sched_yield() in the shmclient, and that helps.
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.
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.
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.
These processes could be a disk server, a GUI, etc.
Question: does the same "shared memory" problem occur with threads?
Intuitively there should not be problems, but never know after what
I have seen.
Best regards,
Juhana
13 Jul
13 Jul
9:42 a.m.
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
10:27 a.m.
On Sat, 2003-07-12 at 22:32, Juhana Sadeharju wrote:
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.
I haven't got any problems with shared memory, but afterall, I don't use
the SystemV method (shm* functions) because it sucks. I think the
SystemV IPC stuff sucks as whole. I like to use the "real" POSIX way..
:)
--
Jussi Laako <jussi.laako(a)pp.inet.fi>
8027
days inactive
8028
days old
linux-audio-dev@lists.linuxaudio.org
2 comments
3 participants
participants (3)
-
Ingo Oeser -
Juhana Sadeharju -
Jussi Laako