[linux-audio-dev] Re: Shared memory

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