Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!usc!
elroy.jpl.nasa.gov!ncar!noao!arizona!william
From: will...@cs.arizona.edu (Dragon (William Hertling))
Newsgroups: comp.os.linux
Subject: Thread Package for Linux
Message-ID: <40251@optima.cs.arizona.edu>
Date: 20 May 93 22:21:39 GMT
Sender: n...@cs.arizona.edu
Organization: U of Arizona CS Dept, Tucson
Lines: 21
I'm about to port xkernel to linux. xkernel is (close to) an OO interface
for networking code. I'm only planning to port the xkernel simulator
at this point in time, though if that works out, I may try to put
the xkernel code right into the linux kernel. However, what I
really need right now is a lightweight threads package for linux.
xkernel currently runs under SunOS, and uses Sun's thread package.
Can anyone point me towards a thread package for linux? If there
are several, which is most similar to Sun's?
If nothing is available for linux, how about a thread package for
BSD that I could port to linux?
I would appreciate any help possible, by email, or by
posts back to this newsgroup. Email is preferred.
William Hertling
Internet: will...@cs.arizona.edu
Phonenet: 602.795.7626
Path: gmd.de!rrz.uni-koeln.de!unidui!easix!exnet2!dorothy.ibmpcug.co.uk!
pipex!uknet!doc.ic.ac.uk!agate!howland.reston.ans.net!darwin.sura.net!
cc.gatech.edu!gatech!prism!gt8134b
From: gt81...@prism.gatech.EDU (Howlin' Bob)
Newsgroups: comp.os.linux
Subject: Re: Thread Package for Linux
Keywords: thread linux clone
Message-ID: <99564@hydra.gatech.EDU>
Date: 28 May 93 00:57:53 GMT
References: <scottl.738445219@fish.dev.cdx.mot.com> <1u1rdg$gds@blips.isi.edu>
<1993May27.224157.13041@kf8nh.wariat.org>
Distribution: git
Organization: Georgia Institute of Technology
Lines: 24
In <1993May27.224157.13...@kf8nh.wariat.org> b...@kf8nh.wariat.org
(Brandon S. Allbery) writes:
>Last time I looked at System V semaphores, they were a nightmare to use. Are
>Linux's semaphores better in this respect? If not, then maybe we need a
>simpler semaphore package to make this worth doing. But since the "philos"
>demo source doesn't look *that* horrid, maybe they'll do.
Linux's semaphores *are* SYSV semaphores. I wouldn't say they're
horrid, but then again I wouldn't recommend using them without
wrapper functions of some sort. They're fairly powerful--
"too powerful" is a common complaint--but there a few technical
flaws in addition to the difficulty in use. One example of
this is that a semaphore cannot be created and initialized
as an atomic operation. I've never needed this, but I can
imagine instances in which it would be useful. The
Stevens book "Advanced Programming in the UNIX Environment" has
a fairly good section about semaphores; the Bach book is also
useful.
--
Robert Sanders
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt8134b
Internet: gt81...@prism.gatech.edu
Newsgroups: comp.os.linux
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!torn!nott!bnrgate!
bnr.co.uk!uknet!cf-cm!cybaswan!iiitac
From: iii...@swan.pyr (Alan Cox)
Subject: Re: Thread Package for Linux
Message-ID: <1993May28.093047.4261@swan.pyr>
Keywords: thread linux clone
Organization: Swansea University College
References: <scottl.738445219@fish.dev.cdx.mot.com> <1u1rdg$gds@blips.isi.edu>
<1993May27.224157.13041@kf8nh.wariat.org>
Date: Fri, 28 May 1993 09:30:47 GMT
Lines: 15
In article <1993May27.224157.13...@kf8nh.wariat.org> b...@kf8nh.wariat.org
(Brandon S. Allbery) writes:
>Last time I looked at System V semaphores, they were a nightmare to use. Are
>Linux's semaphores better in this respect? If not, then maybe we need a
>simpler semaphore package to make this worth doing. But since the "philos"
>demo source doesn't look *that* horrid, maybe they'll do.
Linux copies the sys5 ipc. It works its horrid and maybe the wheel should
have been re-invented to be round instead of square in this case.
The lightweight threads share memory space so I suspect judicious use
of 386/486 properties - notably the exchange register and memory instruction
properties to do spinlocks combined with a signal would work.
Alan
Newsgroups: comp.os.linux
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!usc!elroy.jpl.nasa.gov!
decwrl!netcomsv!netcom.com!jeffrey
From: jeff...@netcom.com (Jeffrey Kegler)
Subject: Re: Thread Package for Linux
Message-ID: <jeffreyC7r6yM.E7E@netcom.com>
Keywords: thread linux semaphore
Organization: Algorists, Inc.
References: <1u1rdg$gds@blips.isi.edu> <1993May27.224157.13041@kf8nh.wariat.org>
<1993May28.093047.4261@swan.pyr>
Date: Fri, 28 May 1993 20:15:57 GMT
Lines: 51
In article <1993May28.093047.4...@swan.pyr> iii...@swan.pyr (Alan Cox) writes:
>In article <1993May27.224157.13...@kf8nh.wariat.org> b...@kf8nh.wariat.org
(Brandon S. Allbery) writes:
>>Last time I looked at System V semaphores, they were a nightmare to use. Are
>>Linux's semaphores better in this respect?
>
>Linux copies the sys5 ipc. It works its horrid and maybe the wheel should
>have been re-invented to be round instead of square in this case.
I'd like to speak up in partial defense of System V semaphores. A
major part of the interface's complexity, and (I suspect) a major
source of the complaints against it is that it forces the user, instead
of requesting operations on particular semaphores, to create complex
structures specifying a set of semaphore-operation pairs, and to pass
that address as an argument. This is required even where a single
simple operation on one semaphore is wanted. And after all, one might
ask, can't multiple semaphore operations be accomplished just as well
by a sequence of calls?
This is a actually a feature, whose utility is often missed even in one
excellent text devoted to details of IPC programming. In some complex
situations, the best way to avoid deadlocks is to do semaphore
operations in sets, atomically. The System V mechanism guarantees all
semaphore-operation pairs in a set will be done atomically, that is,
simultaneously from the point of view of other system process. A
semaphore facility which lacks this ability loses much of its utility
in more complex situations -- and, after all, for simple situations we
did have tricks we could use in place of a real semaphore facility.
The way to get our cake and eat it, too, is to create a library which
makes it handy to handle the single semaphore operations, which will be
most common.
I have no great love for System V IPC, but System V semaphores are the
subject of much unfair criticism alleging they violate the rule of
minimalism for kernel calls and are unnecessarily hard to use as well.
The fact is that many of the alternatives are not minimal but
sub-minimal -- they don't provide the atomicity of sets of semaphore
operations, which only a kernel call can give.
Perhaps this post is in vain, because I am guessing what the other
poster's problems with this interface are -- they weren't laid out in
detail. I'd hate to see Linux move to a semaphore facility which was a
regression, lacking precisely the features essential to those
applications which most need semaphores.
--
Jeffrey Kegler, Independent UNIX Consultant, Algorists, Inc.
jeff...@algor2.ALGORISTS.COM
137 E Fremont AVE #122, Sunnyvale CA 94087
"There is no such thing as quality control. There is truth, and
there is honor." -- from an interview with Carl Landegger, CEO of
Black Clawson, on CNN's "Pinnacle" series.
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!usenet.ins.cwru.edu!
magnus.acs.ohio-state.edu!cis.ohio-state.edu!skink.cis.ohio-state.edu!balasub
From: bala...@skink.cis.ohio-state.edu (Krishna Balasubramanian)
Newsgroups: comp.os.linux
Subject: System V IPC (was Re: Thread Package for Linux)
Date: 28 May 1993 19:01:54 -0400
Organization: Ohio State Computer Science
Lines: 25
Sender: bala...@cis.ohio-state.edu
Message-ID: <BALASUB.93May28190148@skink.cis.ohio-state.edu>
References: <1993May28.075134.5130@nuscc.nus.sg>
<1993May28.112917.16709@kf8nh.wariat.org>
NNTP-Posting-Host: skink.cis.ohio-state.edu
In-reply-to: bsa@kf8nh.wariat.org's message of Fri, 28 May 1993 11:29:17 GMT
Jeffrey spoke clearly in partial defense of sysv ipc semaphores.
I've run into quirks but stayed with the 'standard' as well as I could.
Checking array operations is going to cost something even if we
streamline the implementation. First I'd be happy to determine
that it's bug free!
As noted in ipc.texi and sys/sem.h ... if you just want P and V
you can use test_bit(), set_bit() and clear_bit() .... defined
in <asm/bitops.h> and included by <sys/sem.h> for this purpose.
Guess we are stuck with sysv ipc until there is a better standard.
Meanwhile, we could look into sysv compatible changes. Every
ipc release has requested such suggestions ... we should have
had this discussion earlier.
I have yet to look at Stevens' suggestions... (someone borrowed
my copy of Network Programming before I got to it) ... Are they
sysv compatible? perhaps someone cares to summarize them?
Does Xenix offer more than P and V?
krishna
Newsgroups: comp.os.linux
Path: gmd.de!Germany.EU.net!news.dfn.de!darwin.sura.net!wupost!uunet!
munnari.oz.au!cs.mu.OZ.AU!munta.cs.mu.OZ.AU!fjh
From: f...@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Thread Package for Linux
Message-ID: <9314923.26467@mulga.cs.mu.OZ.AU>
Keywords: thread linux semaphore
Sender: n...@cs.mu.OZ.AU
Organization: Computer Science, University of Melbourne, Australia
References: <1u1rdg$gds@blips.isi.edu> <1993May27.224157.13041@kf8nh.wariat.org>
<1993May28.093047.4261@swan.pyr> <jeffreyC7r6yM.E7E@netcom.com>
Date: Sat, 29 May 1993 13:51:14 GMT
Lines: 35
jeff...@netcom.com (Jeffrey Kegler) writes:
>
>The way to get our cake and eat it, too, is to create a library which
>makes it handy to handle the single semaphore operations, which will be
>most common.
>
>I have no great love for System V IPC, but System V semaphores are the
>subject of much unfair criticism alleging they violate the rule of
>minimalism for kernel calls and are unnecessarily hard to use as well.
>The fact is that many of the alternatives are not minimal but
>sub-minimal -- they don't provide the atomicity of sets of semaphore
>operations, which only a kernel call can give.
SysV semaphores are great if you really need that level of functionality,
and you are right that it's necessary to have them in the kernel.
Furthemore they are even portable! :-)
However, most of the time you *don't* need that level of functionality,
and then the SysV semaphores are not only too complex, they're also too
slow. We need another simpler interface which can be implemented more
efficiently (i.e. *not* just as calls to the SysV interface).
I don't suppose there is any standard or semi-standard semaphore
facility apart from the SysV stuff, is there? (I know that SGI has it's
own system-specific semaphore library in addition to supporting the
SysV stuff, as does our ENCORE MULTIMAX.) Maybe POSIX threads come
with fast (simple) semaphores?
The Linux fast mutexes / fast semaphores should be implemented using
<asm/bitops.h>.
--
Fergus Henderson This .signature virus might be
f...@munta.cs.mu.OZ.AU getting old, but you still can't
consistently believe it unless you
Linux: Choice of a GNU Generation copy it to your own .signature file!
Newsgroups: comp.os.linux
Path: gmd.de!Germany.EU.net!mcsun!uunet!sybus.sybus.com!myrddin!tscs!fin!chip
From: c...@fin.uucp (Chip Salzenberg)
Subject: Re: SysV IPC (was Re: Thread Package for Linux)
Keywords: thread linux semaphore
References: <1u1rdg$gds@blips.isi.edu> <1993May28.093047.4261@swan.pyr>
<jeffreyC7r6yM.E7E@netcom.com> <9314923.26467@mulga.cs.mu.OZ.AU>
Organization: Fantastic Information Network
Date: Sat, 29 May 1993 18:35:31 GMT
Message-ID: <C7swz8.x5@fin.uucp>
Lines: 12
According to f...@munta.cs.mu.OZ.AU (Fergus James HENDERSON):
>SysV semaphores are great if you really need that level of functionality,
>and you are right that it's necessary to have them in the kernel.
Yeah. I think they're okay, mostly. It's just that, like the rest of
SysV IPC, they aren't in the filesystem! Their names ("keys") are
arbitrary four-byte numbers. Bleh and double bleh.
--
Chip Salzenberg, at home <c...@fin.uucp> or <tscs!fin!chip>
* Tailfin smarts from orca bite
* Waters ahead hide dangers unknown
* Still I chase fish and laugh *
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!math.ohio-state.edu!
magnus.acs.ohio-state.edu!cis.ohio-state.edu!skink.cis.ohio-state.edu!balasub
From: bala...@skink.cis.ohio-state.edu (Krishna Balasubramanian)
Newsgroups: comp.os.linux
Subject: Re: System V semaphores: I always thought something seemed wrong...
Date: 30 May 1993 00:10:39 -0400
Organization: Ohio State Computer Science
Lines: 57
Sender: bala...@cis.ohio-state.edu
Message-ID: <BALASUB.93May30001033@skink.cis.ohio-state.edu>
References: <1993May30.000612.1998@kf8nh.wariat.org>
NNTP-Posting-Host: skink.cis.ohio-state.edu
In-reply-to: bsa@kf8nh.wariat.org's message of Sun, 30 May 1993 00:06:12 GMT
To double-check some thoughts I've been having on semaphores I have been
perusing the ipcdelta sources. What I found sent me on a search of the SysV
manuals, where it seems to have been confirmed:
(1) SysV semaphores do no deadlock checking (!)
Deadlock checking of any sort would be very expensive (if possible).
Semaphores are usually regarded as primitive and dangerous and hence
the need for higher level mechanisms. Normally such mechanisms would be
designed with a specific purpose in mind which might not be suitable
for all applications. I am happy as long as any deadlocks that occur
are my own creation...give me them semaphores and let me play.
(2) SEM_UNDO is d*mned near *required*: if a process exits without releasing
any semaphores that it currently "owns" (read: dumps core :-} ) and
SEM_UNDO wasn't specified in the request that seized the semaphore, it
won't be released. ???????? I thought this looked funny when I looked
at the SysV manpages the first time; now it looks ominous.
Yes ... I have reservations about SEM_UNDO and it does seem to be
needed in one form or another. Perhaps a SEM_RESTORE which resets
the semaphore to a sane state on exit? but that doesn't solve the
problem below.
The current implementation places no restrictions on SEM_UNDO requests
... silently ignoring ones that will not go through. An unrestricted
implementation is begging for inconsistencies as SEM_UNDO does not
undo all operations on the semaphore but only those with undo requests
by the current process. Dont see a simple solution ....
Since this seems to be the standard SysV behavior, am I missing
something that makes this not as bad as it seems, or is this a
deficiency (or a pair of deficiencies?) in SysV semaphores?
Not really ... I think ... programs should not crash ... when they do,
one does what one can and that may not be ideal. Anyone have a better idea?
[BTW, for the person who didn't think my complaints about "System V" were
appropriate: please understand that I am most emphatically a System V person
--- but that doesn't mean I'm willing to ignore the warts. I'd rather see
them fixed so System V becomes better....]
++Brandon
Dont know who that was ... but I think we're having a reasonable
discussion. Perhaps it is that they were more wary of deviating from
standards ... My feeling is that the average knucklehead in a
standards comittee is a little more experienced than me as a unix
programmer ... of course times are a changing and so must standards ...
I guess I'm more of a native born linuxer ... know it better than
any other unix and also learned most I know of unix from reading
linux source. It happened that I was doing some OS courses and I'd
played with sysv IPC before so I decided to try implementing it.
krishna
Newsgroups: comp.os.linux
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!ux1.cso.uiuc.edu!
moe.ksu.ksu.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news.weeg.uiowa.edu!
bmandrsn
From: bmand...@news.weeg.uiowa.edu (Bryan M. Andersen)
Subject: Re: System V semaphores: I always thought something seemed wrong...
Message-ID: <1993May31.152927.14274@news.weeg.uiowa.edu>
Organization: University of Iowa, Iowa City, IA, USA
References: <1993May30.000612.1998@kf8nh.wariat.org>
<BALASUB.93May30001033@skink.cis.ohio-state.edu>
Date: Mon, 31 May 1993 15:29:27 GMT
Lines: 52
bala...@skink.cis.ohio-state.edu (Krishna Balasubramanian) writes:
> (2) SEM_UNDO is d*mned near *required*: if a process exits without releasing
> any semaphores that it currently "owns" (read: dumps core :-} ) and
> SEM_UNDO wasn't specified in the request that seized the semaphore, it
> won't be released. ???????? I thought this looked funny when I looked
> at the SysV manpages the first time; now it looks ominous.
>Yes ... I have reservations about SEM_UNDO and it does seem to be
>needed in one form or another. Perhaps a SEM_RESTORE which resets
>the semaphore to a sane state on exit? but that doesn't solve the
>problem below.
>The current implementation places no restrictions on SEM_UNDO requests
>... silently ignoring ones that will not go through. An unrestricted
>implementation is begging for inconsistencies as SEM_UNDO does not
>undo all operations on the semaphore but only those with undo requests
>by the current process. Dont see a simple solution ....
You're right there is no simple solution.
There are problems with having a processes semaphors undone when
it exits abnormally. What happens if it was in the middle of updating
a shared data structure? Do you want another process which was
waiting to access that shared data structure to go ahead and use it? I
doubt it as the shared data structure is likely corupted and exception
processing needs to be done to fix any inconsistancies before any
aditional use of the shared data structure can be safely done. Now
if the semaphore handling mechanisms don't have the ability to clear
or back out the semaphore requests/holds of a dead process by another
process. Then maby that should be addresed rather than to make dead
processes semaphore requests/holds going away apon exit. Unfortunatly
I'm not familular with SysV semaphore system, but it is very clear to
me that you can't assume that it's ok to clear a processes semaphores
on exit or abort. It is the job of the programmer using the
semaphores to do that.
I'm in favor of extending the capibilities of the semaphore system
while maintaing backward compatibility with the pre-existing system.
It's a nightmare trying to port code from one semaphore system to another
if they behave differently. Make the default SysV compatible and add
the functionality that is logically needed.
Bryan Andersen <bryan-ander...@uiowa.edu>
<bmand...@umaxc.weeg.uiowa.edu>
--
--
Bryan M. Andersen <bmand...@umaxc.weeg.uiowa.edu> [for giggles sex, kill, drugs,
rock-n-roll, FBI, CIA, NSA (Hi!), death. Giggles cocaine, bondage, president,
scandal, impeachment. Marijuana, pot, joint, hemp, legalize, industrial use]
Newsgroups: comp.os.linux
Path: gmd.de!newsserver.jvnc.net!yale.edu!spool.mu.edu!olivea!uunet!
news.crd.ge.com!ariel!davidsen
From: david...@ariel.crd.GE.COM (william E Davidsen)
Subject: Re: System V semaphores: I always thought something seemed wrong...
Message-ID: <C808nx.LKy@crdnns.crd.ge.com>
Sender: use...@crdnns.crd.ge.com (USENET News System)
Nntp-Posting-Host: ariel.crd.ge.com
Reply-To: david...@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY
References: <1993May30.000612.1998@kf8nh.wariat.org>
Date: Wed, 2 Jun 1993 17:31:09 GMT
Lines: 23
In article <1993May30.000612.1...@kf8nh.wariat.org>, b...@kf8nh.wariat.org
(Brandon S. Allbery) writes:
| Since this seems to be the standard SysV behavior, am I missing something that
| makes this not as bad as it seems, or is this a deficiency (or a pair of
| deficiencies?) in SysV semaphores?
Well, I'm not sure I see it as a deficiency, but you read it
correctly. If the program is at risk of dumping or otherwise not
cleaning up on exit, SysV provides the SEM_UNDO flag to insure that
things are cleaned up.
There are cases in which you really want to leave things locked
because some other resource (like database?) may be left unusable after
a crash, so it's not always wrong to leave the lock in.
I don't think the default is so wrong that I would want to change it,
but it's certainly debatable if the meaning and default on the UNDO
action should be reversed, and SEM_NO_UNDO be the special case. I would
rather be compatible with SysV, since that makes the code more portable.
--
bill davidsen, GE Corp. R&D Center; 518-387-6489
Look for a new corporate affiliation, coming to this space soon.
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!gatech!prism!gt8134b
From: gt81...@prism.gatech.EDU (Howlin' Bob)
Newsgroups: comp.os.linux
Subject: Re: Thread Package for Linux
Keywords: thread linux semaphore
Message-ID: <100438@hydra.gatech.EDU>
Date: 3 Jun 93 01:11:45 GMT
References: <1u1rdg$gds@blips.isi.edu> <jeffreyC7r6yM.E7E@netcom.com>
<9314923.26467@mulga.cs.mu.OZ.AU> <C807H1.K6u@crdnns.crd.ge.com>
<1993Jun2.225846.27329@kf8nh.wariat.org>
Organization: Georgia Institute of Technology
Lines: 80
In <1993Jun2.225846.27...@kf8nh.wariat.org> b...@kf8nh.wariat.org
(Brandon S. Allbery) writes:
>You see what I mean about ugly? The Xenix variant was *very* *badly* mapped
>into the filesystem namespace, even considering that semaphores don't have
I agree. With this kind of non-orthogonality, I'd consider their
presence in the file namespace more a blight than a feature.
>My own variant uses any inode as a semaphore, requiring no new filesystem
>objects. Thus, opensem(), creatsem(), and closesem() are no longer needed;
>the ordinary file operations will do. Two new system calls are added; I chose
Did you add more fields to the in-core inode structure?
Realize that inodes are not cheap. as of 0.99pl10 we have a more
flexible inode allocation scheme, but it's best to leave things
that don't *have* of use inodes out of them. The fewer the
inodes, the better the hashing works.
>already been reports of SysV semaphore slowness (Robert Sanders of dosemu fame
>has already posted about that); the sigsem() and waitsem() system calls are
fame? Perhaps not. If anything, I expect that my name wil
live on in minor infamy after my work with dosemu, at least in
the mind of whomever inherits the beast.
I never claimed that SYSV semaphores are slow. I was probably
verbally sloppy about it, but that's wasn't what I was implying.
What I said was this: in certain situations, *any* continual
acquiring and releasing of *any* type of semaphore can be too much
overhead. My situation entails two processes sharing some memory,
with one process being the primary user, the other secondary one
only occasionally and for short periods needing access. dosemu
needs to loop through these "critical" regions in the primary
process many, many times a second. Given, semaphores are supposed to
be lightweight, but I need something even less burdensome. My
situation best fits itself to the secondary process somehow halting
the primary process when it needs access (SIGSTOP is a mechanism
available now). Of course, this only works because the primary
process can be interrupt at any time within this critical region;
it is the secondary process that needs to have exclusive access.
I don't think my scenario is too common. Linux *does* need very
low-overhead semaphores. I don't know if our SYSV semaphores fit
the bill or not. I know that Krishna Balasubramanian, the author,
concentrated mostly on shared memory, adding the semaphores and
message queues for completeness. But if the semaphores are as
good as the shared memory, I'm sure they're fine.
You might want to put some effort into speeding up the SYSV semaphores.
An obvious optimization is to bias the routines towards what
I believe would be the most common case: one semaphore per semaphore
array. Since SYSV IPC is in the kernel now, it's best to work on
that.
>very small and fast, whereas read() and write() are slower because they're
>intended for a more general purpose --- and I would need to implement
>namefiles, and P and V would have to be done through the VFS mechanism. I
>don't know how much of a slowdown *that* would cause as compared to the direct
>one I implemented, and, frankly, VFS is pretty irrelevant to semaphores
>anyway.
Yes, you'd be going through a switch to get back to the same place you
started. Even so, I don't expect that the slowdown would be significant.
I like many aspects of your approach. It's rather clean to perform
semaphore operations on the file you're trying to arbitrate access to,
for example. Perhaps using an inode per semaphore is rather expensive,
though. SYSV semaphores have an advantage in this regard, as the cost
per semaphore decreases with the number of semaphores in the array.
I don't expect that most applications will need too many semaphores,
but large things like Postgres probably use quite a few (he says with no
data to back it up).
--
Robert Sanders
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt8134b
Internet: gt81...@prism.gatech.edu
Path: gmd.de!newsserver.jvnc.net!darwin.sura.net!news-feed-1.peachnet.edu!
gatech!prism!gt8134b
From: gt81...@prism.gatech.EDU (Howlin' Bob)
Newsgroups: comp.os.linux
Subject: Re: Thread Package for Linux
Keywords: thread linux semaphore
Message-ID: <100535@hydra.gatech.EDU>
Date: 3 Jun 93 14:11:04 GMT
References: <1u1rdg$gds@blips.isi.edu> <C807H1.K6u@crdnns.crd.ge.com>
<1993Jun2.225846.27329@kf8nh.wariat.org> <100438@hydra.gatech.EDU>
<1993Jun3.120112.31966@kf8nh.wariat.org>
Organization: Georgia Institute of Technology
Lines: 37
In <1993Jun3.120112.31...@kf8nh.wariat.org> b...@kf8nh.wariat.org
(Brandon S. Allbery) writes:
>In article <100...@hydra.gatech.EDU> gt81...@prism.gatech.EDU
(Howlin' Bob) writes:
>I'm more likely to fix the inode allocation scheme. I've already had to raise
>the limits in my kernel --- and that was *before* I did the Xenix semaphore
>code.
I do believe that 0.99pl0 dynamically allocates inodes. That doesn't
mean that inodes are free, however.
>(2) I figured that, more often than not, a semaphore would be used to
>synchronize access to a file (And still more often when mmap() works
>properly);
I do like the association of the semaphore and the file. As for
mmap()...it's being discussed.
Using inodes is inevitable here, I suppose.
>>it is the secondary process that needs to have exclusive access.
>Yes. How many situations of this sort are there, compared to cases which
>require mutual exclusive access? I can't quite see how yours would come
>about, even; have to look at the code next time I get a chance.
Well, I *did* say it was unusual. It's also unimplemented. I'm using
SYSV semaphores to arbitrate access. I do have performance problems,
but not because of the semaphores (I believe).
--
Robert Sanders
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt8134b
Internet: gt81...@prism.gatech.edu
Newsgroups: comp.os.linux
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!usc!cs.utexas.edu!
uunet!news.crd.ge.com!ariel!davidsen
From: david...@ariel.crd.GE.COM (william E Davidsen)
Subject: Re: Thread Package for Linux
Message-ID: <C83n9C.BzE@crdnns.crd.ge.com>
Keywords: thread linux semaphore
Sender: use...@crdnns.crd.ge.com (USENET News System)
Nntp-Posting-Host: ariel.crd.ge.com
Reply-To: david...@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY
References: <1u1rdg$gds@blips.isi.edu> <jeffreyC7r6yM.E7E@netcom.com>
<9314923.26467@mulga.cs.mu.OZ.AU> <C807H1.K6u@crdnns.crd.ge.com>
<1993Jun2.225846.27329@kf8nh.wariat.org> <100438@hydra.gatech.EDU>
Date: Fri, 4 Jun 1993 13:39:12 GMT
Lines: 17
In article <100...@hydra.gatech.EDU>, gt81...@prism.gatech.EDU (Howlin' Bob)
writes:
| I like many aspects of your approach. It's rather clean to perform
| semaphore operations on the file you're trying to arbitrate access to,
| for example.
Um, that's what region locking is for... if you want to controll
access to the whole file, you just agree to lock the first byte, then
use the whole thing. I do that in some versions of MBS (a BBS) and it
seems to work pretty well, at least based on some measurements I've
taken. It definitely works in terms of controlling access, I haven't
timed other approaches, since I was trying to avoid using semiphores for
other reasons.
--
bill davidsen, GE Corp. R&D Center; 518-387-6489
Look for a new corporate affiliation, coming to this space soon.
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!gatech!prism!
gt8134b
From: gt81...@prism.gatech.EDU (Howlin' Bob)
Newsgroups: comp.os.linux
Subject: Re: Thread Package for Linux
Keywords: thread linux semaphore
Message-ID: <100740@hydra.gatech.EDU>
Date: 4 Jun 93 14:26:08 GMT
References: <1u1rdg$gds@blips.isi.edu> <jeffreyC7r6yM.E7E@netcom.com>
<9314923.26467@mulga.cs.mu.OZ.AU> <C807H1.K6u@crdnns.crd.ge.com>
<1993Jun2.225846.27329@kf8nh.wariat.org> <100438@hydra.gatech.EDU>
<C83n9C.BzE@crdnns.crd.ge.com>
Organization: Georgia Institute of Technology
Lines: 33
In <C83n9C....@crdnns.crd.ge.com> david...@ariel.crd.GE.COM
(william E Davidsen) writes:
>In article <100...@hydra.gatech.EDU>, gt81...@prism.gatech.EDU
(Howlin' Bob) writes:
>| I like many aspects of your approach. It's rather clean to perform
>| semaphore operations on the file you're trying to arbitrate access to,
>| for example.
> Um, that's what region locking is for... if you want to controll
True. In fact, the Stevens book suggests using file locks for all
semaphores. However, since he obviously found some reason to use
Xenixish semaphores--whether for porting or for speed--I was
discussing the merits of his approach.
>use the whole thing. I do that in some versions of MBS (a BBS) and it
>seems to work pretty well, at least based on some measurements I've
>taken. It definitely works in terms of controlling access, I haven't
Stevens' figures show that, on the systems he tested, file locking was
somewhat slower than SYSV semaphores. Due to his distaste for SYSV
semephores, he considered the extra overhead "acceptable." Perhaps
Mr. Allbery wouldn't agree.
Still, it is true that filesystem-based semaphores could be implemented
with library routines that use the existing advisory file locking
mechanism.
--
Robert Sanders
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt8134b
Internet: gt81...@prism.gatech.edu
Newsgroups: comp.os.linux
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!gatech!hubcap!
ncrcae!ncrhub2!torynews!kevin
From: ke...@TorreyPinesCA.ncr.com (Kevin Sanders)
Subject: Re: SysV IPC (was Re: Thread Package for Linux)
Message-ID: <1993Jun1.211846.17217@TorreyPinesCA.ncr.com>
Keywords: thread linux semaphore
Organization: NCR (Torrey Pines Development Center)
Disclaimer: This posting does not necessarily reflect the opinions of NCR.
References: <9314923.26467@mulga.cs.mu.OZ.AU> <C7swz8.x5@fin.uucp>
<1993May30.214832.12063@kf8nh.wariat.org>
Date: Tue, 1 Jun 93 21:18:46 GMT
Lines: 24
In article <1993May30.214832.12...@kf8nh.wariat.org> b...@kf8nh.wariat.org
(Brandon S. Allbery) writes:
>In article <C7swz8...@fin.uucp> c...@fin.uucp (Chip Salzenberg) writes:
>>
>>Yeah. I think they're okay, mostly. It's just that, like the rest of
>>SysV IPC, they aren't in the filesystem! Their names ("keys") are
>>arbitrary four-byte numbers. Bleh and double bleh.
>
>So? My Xenix-compatible semaphore code shows just how disgustingly ugly
>semaphores that *are* in the filesystem namespace are. Also see "Unix domain
>sockets" for more bletcherous attempts to force non-file-system square pegs
>into filesystem round holes. Shared memory is arguable; semaphores and
>message queues don't fit any better than the socket hack does (in fact,
>message queues fit precisely as badly as AF_UNIX sockets do).
It's OK that the keys are 4-byte numbers, and that they aren't in the
filesystem. How about putting them in the /proc filesystem? Then we can
make everybody happy.
--
[] [] [][] [][] Kevin Sanders, KN6FQ NCR Torrey Pines
[] [] [] [] [] kevin.sand...@torreypinesca.ncr.com (619) 597-3602
[][] [][] [][] kevin%beac...@cyber.net
[] [] [] [] [] - The more we disagree, the more chance there is
[] [] [] [] [][] - that at least one of us is right.
Path: gmd.de!xlink.net!howland.reston.ans.net!gatech!prism!gt8134b
From: gt81...@prism.gatech.EDU (Howlin' Bob)
Newsgroups: comp.os.linux
Subject: Re: SysV IPC (was Re: Thread Package for Linux)
Keywords: thread linux semaphore
Message-ID: <101363@hydra.gatech.EDU>
Date: 9 Jun 93 02:03:28 GMT
References: <9314923.26467@mulga.cs.mu.OZ.AU> <C7swz8.x5@fin.uucp>
<1993May30.214832.12063@kf8nh.wariat.org>
<1993Jun1.211846.17217@TorreyPinesCA.ncr.com>
Organization: Georgia Institute of Technology
Lines: 24
In <1993Jun1.211846.17...@TorreyPinesCA.ncr.com> ke...@TorreyPinesCA.ncr.com
(Kevin Sanders) writes:
>It's OK that the keys are 4-byte numbers, and that they aren't in the
>filesystem. How about putting them in the /proc filesystem? Then we can
>make everybody happy.
Just to really disgust everybody, I'll tell you about what I was going
to do with /proc/ipc/{shm,sem,msg}. I was going to have every message
queue in /proc/ipc/msg, and -- although you still accessed message queues
through the SYSV functions -- you could also non-destructively "peek"
at the queues with read(), and (the reason I thought of it), you
could select() on a message queue. Why? Because I needed to poll
character devices and message queues at the same time.
Needless to say, I found another way.
/proc will soon hold everything. As someone once said, you'll be able to
recompile the kernel from /proc/kernelsrc :-)
--
Robert Sanders
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt8134b
Internet: gt81...@prism.gatech.edu
|