Re: unused shared objects in /dev/shm/ngpt

Am Dienstag den, 27. August 2002, um 07:52, schrieb Dr. Uwe Girlich:
>
> I'm playing a bit with shared objects and find the whole concept a bit 
> fragile:
> I create a lot of shared mutexes and shared conditional variables in 
> some
> shared memory. Then all programs, using these shared objects (and the 
> shared
> memory holding them) will be killed and the shared memory will disappear
> (either via ipcrm or because the shared memory id was removed already 
> and so
> the last detach (in the exit() system call) will destroy the shared 
> memory
> segment).

ipcrm is only usable with SysV ipc - but I think you are still right: 
the system can
easily run out of IPC objects. And since shm/ngpt is world writable, 
every user
can bring "the system" (of cooperating procs/threads) down, or doing 
other havoc.
I thought about a per user file (like ngpt-$UID). But this gives you 
trouble when
processes with different euid want to cooperate (here you have another 
level of
indirection, i.e. what gid do you choose, to provide proper permissions?)

I think the only sane way is to store the futexes in proper protected 
POSIX shmem
objects (with usual filesystem permission bits) - see below.

> Now the problem: NGPT uses /dev/shm/ngpt as an extra space for shared
> objects, and now we have no pointer to the just unused shared objects 
> any
> more. Sooner or later we get ENOMEM as error of pthread_mutext_init(), 
> because
> the file is full of no longer used shared objects.
>

I already thought about that and my only idea about why using a fixed 
sized array
of shared objects was the easier implementation of a lock manager. 
Atleast we
know the location of possible userspace locks without prior registry.

Normally I would instantiate some mutexes/cond in shmem and use that 
within
my processes/threads. My system has to give proper filesystem protection 
for the
shmem arena. Because I have to "pin/lock" the pages for the futexes to 
work - the
kernel could use some resource limits (max locked pages) to prevent 
exhaustive
use by one user.
Furthermore the kernel could release all locks in that page when the 
reference count
drops to zero. For this to work someone has to unlink the POSIX shmem 
first.
This system wouldn't have an arbitrated limit - but still tuneable with 
rlimits to prevent
the system from running out of "unlocked pages".

> Do I need a monitor process to constantly read /dev/shm/ngpt and 
> looking for
> mx_owner_pid values, which no longer exist (and a similar concept for 
> cond.
> variables)?

Unfortunately the kernel does not know anything about the lock unless 
there is
contention. And without looking at the "owner" field, which is not 
easily maintained
without races, the kernel does not know who owns or uses the lock.
If you use a lock manager where the locks has to be registered, you can 
put the
lock entirely into the kernel - perhaps that's best with PROCESS_SHARED 
locks?