Unix Programming - System V semaphore cleanup

Author

System V semaphore cleanup

Tristan

2007-07-13, 10:05 pm

Hello,

I'm working on an application for which I'm trying to implement System
V semaphores as a file locking mechanism, for various reasons that I
won't get into. The problem is that this application is intended to
run on a system indefinitely and in the background, which means that
there is a very realistic chance of it ending in an unusual way (for
instance, via a SIGKILL). I can use the SEM_UNDO command to make sure
the file isn't considered "locked" if the program were started up
again afterwards, but the semaphores still sit around on the system,
taking up resources. I can use the ipcs command via the command line
to get a list of every semaphore, but I haven't been able to find a
way to do this from C++. Does anybody know of a way to get all of the
system semaphores you have read access to, so that they could be
iterated through and cleaned up as necessary?

Cheers,
Tristan

Jens Thoms Toerring

2007-07-15, 10:06 pm

Tristan <Tzazak@gmail.com> wrote:
> I'm working on an application for which I'm trying to implement System
> V semaphores as a file locking mechanism, for various reasons that I
> won't get into. The problem is that this application is intended to
> run on a system indefinitely and in the background, which means that
> there is a very realistic chance of it ending in an unusual way (for
> instance, via a SIGKILL). I can use the SEM_UNDO command to make sure
> the file isn't considered "locked" if the program were started up
> again afterwards, but the semaphores still sit around on the system,
> taking up resources. I can use the ipcs command via the command line
> to get a list of every semaphore, but I haven't been able to find a
> way to do this from C++. Does anybody know of a way to get all of the
> system semaphores you have read access to, so that they could be
> iterated through and cleaned up as necessary?

The first question that comes to mind is what key you use in the
creation of the semaphores. If this isn't IPC_PRIVATE it should
not be a problem to delete all semaphores that are "debris" from
a previous instance of the program that aborted abnormally (or
even re-use them) on startup of your program by using that key
again to "open" them again. If you used IPC_PRIVATE then you must
have some method to identify which semaphores where created by
your program - or how would you know which you need to delete when
you look at the output of the ipcs utitlity? In that case probably
the simplest way to get rid of them is to invoke the ipcs utility
(e.g. via popen()), read in its output and then delete the ones
that were created by your program and aren't needed anymore by in-
voking ipcrm on them (e.g. system() should do for that).

Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de

Roger Leigh

2007-07-16, 4:17 am

Tristan

2007-07-16, 10:07 pm

Thanks for the replies. I forgot to post that I'd found a solution to
this problem. In answer to your questions, I'm trying to avoid the
newer POSIX semaphores for portability reasons, otherwise that would
work wonderfully. The application in question uses tons of user-
defined files, so scanning through all files the program uses isn't a
possibility.
For the curious, I ended up looking in the ipcs source code
(kernel.org, it's part of util-linux) and figuring out how they were
iterated through in there.
Thanks again for the replies,

Tristan

Scott Lurndal

2007-07-24, 7:08 pm

Tristan <Tzazak@gmail.com> writes:
>Thanks for the replies. I forgot to post that I'd found a solution to
>this problem. In answer to your questions, I'm trying to avoid the
>newer POSIX semaphores for portability reasons, otherwise that would
>work wonderfully. The application in question uses tons of user-
>defined files, so scanning through all files the program uses isn't a
>possibility.
>For the curious, I ended up looking in the ipcs source code
>(kernel.org, it's part of util-linux) and figuring out how they were
>iterated through in there.
>Thanks again for the replies,
>
>Tristan
>

This solution kind of obviates your "portability" argument for not
using the POSIX interfaces, however.

scott

Sponsored Links