You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jim Jagielski <ji...@jaguNET.com> on 1997/09/08 17:36:43 UTC
Using semaphore locking
I've only recently looked at the semaphore locking and have a few idea
to make it more portable. Basically, as we do with shared memory,
we can setup the semaphore to automnatically be deleted (IPC_RMID)
when there are no more processes accesing it, rather than using
a atexit() hack.
Sound like a Good Idea to continue?
PS: Shame we can't use a specific slot in scoreboard for this....
--
====================================================================
Jim Jagielski | jaguNET Access Services
jim@jaguNET.com | http://www.jaguNET.com/
"Look at me! I'm wearing a cardboard belt!"
Re[2]: Re[2]: Using semaphore locking
Posted by Pierre-Yves Kerembellec <Pi...@vtcom.fr>.
Le [Tue, 9 Sep 1997 06:10:17 -0400 (EDT)], Jim Jagielski ecrivait :
> > > Ahem,
> > >
> > > IPC_RMID
> > > Remove the semaphore identifier specified by semid from
> >
> > Ooops, sorry Jim ! I was wrong !
> >
> Actually, I was too. The above behavior isn't standard, esp with
> newer, BSD-based systems.
>
> Shame, too, because it makes sense. Course, very little about
> SysV IPC _does_ make sense :) :)
Right indeed ! :-((
But this kind of behaviour still continue to shock me at all time,
for example the creat/open/unlink stuff in FLOCK_SERIALIZED and you
still have a valid file descriptor, even if the file does not exist any
more ! Tell me about portability (just try to do the same think under
Windows 32bits OS ...) ;-)
Regards
Pierre-Yves
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Pierre-Yves KEREMBELLEC Phone # +33 1 46 12 67 50
VTCOM Fax # +33 1 46 12 67 00
40, rue Gabriel Crie E-mail pyk@vtcom.fr
92245 Malakoff Cedex, France Systemes et Reseaux
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Re[2]: Using semaphore locking
Posted by Pierre-Yves Kerembellec <Pi...@vtcom.fr>.
Le [Mon, 8 Sep 1997 16:34:19 -0400 (EDT)], Jim Jagielski ecrivait :
> Ahem,
>
> IPC_RMID
> Remove the semaphore identifier specified by semid from
> the system and destroy the set of semaphores and data
> structure associated with it. This command can only be
> executed by a process that has an effective user ID
> equal to either that of superuser or to the value of
> sem_perm.uid in the data structure associated with
> semid. The identifier and its associated data
> structure are not actually removed until there are no
> more referencing processes. See ipcrm(1), and ipcs(1).
Ooops, sorry Jim ! I was wrong !
Regards,
Pierre-Yves
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Pierre-Yves KEREMBELLEC Phone # +33 1 46 12 67 50
VTCOM Fax # +33 1 46 12 67 00
40, rue Gabriel Crie E-mail pyk@vtcom.fr
92245 Malakoff Cedex, France Systemes et Reseaux
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Re: Using semaphore locking
Posted by Pierre-Yves Kerembellec <Pi...@vtcom.fr>.
Le [Mon, 8 Sep 1997 11:36:43 -0400 (EDT)], Jim Jagielski ecrivait :
> I've only recently looked at the semaphore locking and have a few idea
> to make it more portable. Basically, as we do with shared memory,
> we can setup the semaphore to automnatically be deleted (IPC_RMID)
> when there are no more processes accesing it, rather than using
> a atexit() hack.
Ahem, as mentionned by Dean ("what a lame interface !"), the IPC_RMID
is not used for that purpose ... indeed, you have no mean to delete a
semaphore when the last process exit ...
Regards,
Pyk
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Pierre-Yves KEREMBELLEC Phone # +33 1 46 12 67 50
VTCOM Fax # +33 1 46 12 67 00
40, rue Gabriel Crie E-mail pyk@vtcom.fr
92245 Malakoff Cedex, France Systemes et Reseaux
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Re: Using semaphore locking
Posted by Dean Gaudet <dg...@arctic.org>.
And linux:
IPC_RMID Remove immediately the semaphore set and its
which is where I actually tested code that called IPC_RMID.
Dean
On Mon, 8 Sep 1997, Martijn Koster wrote:
> On Mon, Sep 08, 1997 at 04:46:23PM -0400, Jim Jagielski wrote:
>
> > Not true at all. In all cases I know of, the semaphore is NOT
> > removed until all attached processes detach from it. Now some
> > BSD-based systems have a stipulation that once the IPC_RMID
> > is effective, even if the semaphore still exists, no new
> > processes will be able to attach, but that's the exception.
>
> OK, then please tell me where the `semat` call to attach to a
> semaphore is documented :-)
>
>
> > IPC_RMID
> > ...
> > The identifier and its associated data
> > structure are not actually removed until there are no
> > more referencing processes.
>
> What system is that, Linux? Have you got any code to demonstrate this
> working? It'd be neat, but surprising. Compare:
>
>
> FreeBSD 3.0-CURRENT, man semctl():
>
> IPC_RMID Immediately removes the semaphore set from the system.
>
> IRIX 6.2, man semctl():
>
> IPC_RMID Immediately removes the semaphore set from the system.
>
> SunOS 5.5.1, man semctl():
>
> IPC_RMID Remove the semaphore identifier specified by
> semid from the system and destroy the set of
> semaphores and data structure associated with
> it.
>
> UNIX Internals, Uresh Vahalia:
>
> When a process issues the IP_CRM command, the kernel frees up the
> semaphore in the resource table. The kernel also wakes up any
> processes that have blocked on some semaphore operation; these
> processes return an EIDRM status from the semop call. Once the
> semaphore is removed, processes can no longer access it (wethe using
> the key or semid).
>
> Advanced programming in the UNIX environment, R. Stevens
>
> IPC_RMID Remove the semaphore set from the system. This removal
> is immediate.
>
> -- Martijn Koster, m.koster@pobox.com
>
>
Re: Using semaphore locking
Posted by Martijn Koster <ma...@webcrawler.com>.
On Mon, Sep 08, 1997 at 04:46:23PM -0400, Jim Jagielski wrote:
> Not true at all. In all cases I know of, the semaphore is NOT
> removed until all attached processes detach from it. Now some
> BSD-based systems have a stipulation that once the IPC_RMID
> is effective, even if the semaphore still exists, no new
> processes will be able to attach, but that's the exception.
OK, then please tell me where the `semat` call to attach to a
semaphore is documented :-)
> IPC_RMID
> ...
> The identifier and its associated data
> structure are not actually removed until there are no
> more referencing processes.
What system is that, Linux? Have you got any code to demonstrate this
working? It'd be neat, but surprising. Compare:
FreeBSD 3.0-CURRENT, man semctl():
IPC_RMID Immediately removes the semaphore set from the system.
IRIX 6.2, man semctl():
IPC_RMID Immediately removes the semaphore set from the system.
SunOS 5.5.1, man semctl():
IPC_RMID Remove the semaphore identifier specified by
semid from the system and destroy the set of
semaphores and data structure associated with
it.
UNIX Internals, Uresh Vahalia:
When a process issues the IP_CRM command, the kernel frees up the
semaphore in the resource table. The kernel also wakes up any
processes that have blocked on some semaphore operation; these
processes return an EIDRM status from the semop call. Once the
semaphore is removed, processes can no longer access it (wethe using
the key or semid).
Advanced programming in the UNIX environment, R. Stevens
IPC_RMID Remove the semaphore set from the system. This removal
is immediate.
-- Martijn Koster, m.koster@pobox.com
Re: Using semaphore locking
Posted by Martijn Koster <ma...@webcrawler.com>.
On Mon, Sep 08, 1997 at 11:36:43AM -0400, Jim Jagielski wrote:
> we can setup the semaphore to automnatically be deleted (IPC_RMID)
> when there are no more processes accesing it, rather than using
> a atexit() hack.
Nope, can't do -- the semaphore is detroyed immediately if you use
IPC_RMID. With shmem you attach to it, then IPC_RMID it, and it
doesn't get destroyed until all are detatched. Not so with
semaphores...
-- Martijn Koster, m.koster@pobox.com