Re: [boost] [Interprocess] Lengthy test runtimes

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2007-08-07 03:41:37

K. Noel Belcourt wrote:
> I should have mentioned that I ran ipcs, here's the output.
> 
> [~]$ ipcs -a
> 
> ------ Shared Memory Segments --------
> key        shmid      owner      perms      bytes      nattch     status
> 0x00000000 0          root      777        94208      0
> 0x00000000 65537      root      777        94208      1
> 
> ------ Semaphore Arrays --------
> key        semid      owner      perms      nsems
> 
> ------ Message Queues --------
> key        msqid      owner      perms      used-bytes   messages
> 
> What kind of IPC object does this test create?  Why is there no IPC  
> object in the kernel data structures?   I don't believe there's  
> anything running on my system that would call ipcrm. 

This depends on the system, but for the moment it creates a shared 
memory with an anonymous mutex. Interprocess uses POSIX primitives (see 
/dev/shm or /dev/sem for POSIX resources) instead of system V ones and 
emulates them with memory mapped files in the temp directory if POSIX 
shared memory is not provided (unistd.h does not define 
POSIX_SHARED_MEMORY_OBJECTS > 0). Your stack points that the thread is 
blocked on:

while(value == InitializingSegment || value == UninitializedSegment){
    detail::thread_yield();
    value = detail::atomic_read32(patomic_word);
}

which means that the thread has found the shared memory created but the 
flag to synchronize the thread opening the segment until the segment is 
initialized by the thread that created the segment is not updated. This 
could mean that the thread that created the segment has been killed 
before initializing properly the segment.

 > There's two
 > copies of this test currently running on my system (gcc-3.4.3 and
 > gcc-4.0.1), would that matter?
 >
> 19303 kbelco    25   0 14944 1380 1188 R 98.9  0.0  40:00.53  
> named_recursive
> 19328 kbelco    25   0 14988 1360 1176 R 98.9  0.0  34:25.73  
> named_recursive

This is really nasty. You should only have one instance, since the test 
is just single-threaded. This can be causing several problems. Can you 
investigate a bit why is this happening?

I'm thinking about the use of shared memory + anonymous synchronization 
objects to emulate named synchronization objects and I think I should 
use native named semaphores when available in systems that provide them. 
I think it will use less resources. Added to my to-do list.

Regards,

Ion