martin@felix.UUCP (Martin McKendry) (01/31/89)
I have a couple of questions about System V implementations
and other Unix systems that implement shared libraries. Since
the answers will reflect system dependencies, and we are
designing for maximum portability, I'd be interested in
answers for any systems, but particularly for the better known
ones -- Suns, 3B2's, Unisys boxes (Convergent?), etc.
o) What is the maximum size of a process? Text space
and data space.
o) How many semaphores are allowed?
o) What tools exist for allocating portions of the address
space among shared libraries? How much space is there?
o) How useful have shared libraries proven in practice for
implementing complex applications? Are other techniques
or combinations of features more useful?
o) Are semaphores the only appropriate technique for implementing
mutual exclusion on small objects? For example, if I had a
large number (say, 2000) of objects that were small (say, 20 bytes),
and I wanted to put locks on each object. Assume that there
are many processes active in the total structure, but they
tend not to interfere with one another. Are semaphores the
mechanism of choice for this problem? It seems like a lot
of overhead to allocate one semaphore per record.
Any answers or input appreciated.
Martin McKendry
--
Martin S. McKendry; FileNet Corp; {hplabs,trwrb}!felix!martin
Strictly my opinion; all of itcrossgl@ingr.com (Gordon Cross) (02/02/89)
In article <81584@felix.UUCP> martin@felix.UUCP (Martin McKendry) writes: > > o) Are semaphores the only appropriate technique for implementing > mutual exclusion on small objects? For example, if I had a > large number (say, 2000) of objects that were small (say, 20 bytes), > and I wanted to put locks on each object. Assume that there > are many processes active in the total structure, but they > tend not to interfere with one another. Are semaphores the > mechanism of choice for this problem? It seems like a lot > of overhead to allocate one semaphore per record. Most machines have an instruction called a "test and set" operation. These instructions allow you to test the current value of a memory location and simultaneously (ie. non-interruptable) set a bit in that location. Using this instruction you can implement what is called a software lock. This approach for locking many small data items (presumably kept in memory that is shared between multiple processes) is MUCH MUCH better than semaphores (even if it was possible to allocate 20,000 of them). In System V there is no routine already provided to use software locks (I don't know about BSD and others) so I had to write my own in assembler (quite small just a couple of instructions). -- Gordon Cross UUCP: uunet!ingr!crossgl "all opinions are 111 Westminister Way INTERNET: crossgl@ingr.com mine and not those Madison, AL 35758 MA BELL: (205) 772-7842 of my employer."
les@chinet.chi.il.us (Leslie Mikesell) (02/04/89)
In article <3747@ingr.com> crossgl@ingr.UUCP (Gordon Cross) writes: >In article <81584@felix.UUCP> martin@felix.UUCP (Martin McKendry) writes: >> o) Are semaphores the only appropriate technique for implementing >> mutual exclusion on small objects? For example, if I had a >> large number (say, 2000) of objects that were small (say, 20 bytes), >> and I wanted to put locks on each object. I'd like to know about this also. My first thought would be to map the objects into a file and use region locks on the file even if the object only exists in shared memory. Can anyone give details about the efficiency of the various IPC mechanisms? Les Mikesell
aglew@mcdurb.Urbana.Gould.COM (02/06/89)
>Most machines have an instruction called a "test and set" operation. These >instructions allow you to test the current value of a memory location and >simultaneously (ie. non-interruptable) set a bit in that location. Beware. There are various degrees of "atomicity" in these so-called "atomic" operations. While nearly all of them are atomic wrt. interrupts on the processor on which the instruction is executed, not all of them are atomic wrt. bus traffic, and/or multiple processors on the bus, etc. Usually these instructions work by asserting a LOCK signal at the external interface of the (micro)processor. It is then up to the system designer to decide what to do with this signal. I have seen systems where the lock signal enforces atomicity only for certain of the set of instructions that might possibly assert it; multiple bus systems where the lock is enforced only on one bus, or in particular address ranges; systems where the lock signal is asserted but requires the cooperation of all devices on the system to be meaningful (typically, distributed arbiter systems) -- and, of course, the device that you need to talk to doesn't cooperate; and systems where the lock is asserted and enforced, but where special operations are needed to program around the behaviour of buffers, queues, and caches. In other words, take care to determine that the "atomic" instruction you are using is indeed atomic with respect to the correct set of system features. (There is an important notion of "relative atomicity" here; I wonder if any academic has ever made such a notion formal?)