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!martinmikey@uunet.uu.net (Mike Lee) (02/09/89)
Yikes, Martin McKendry asked several of the kind of questions one asks before designing a large system. I can only answer one of them: > o) Are semaphores the only appropriate technique for implementing > mutual exclusion on small objects? ... It seems like a lot of > overhead to allocate one semaphore per record. Yes indeedy doodie it's a lot of uberkopf. What works better is to use just one system semaphore to control access to no-touchy bits, which are one to a record. When a process wants to exclude other processes from a record it should do this: a. get the one semaphore b. read in the record (or whatever structure stores the no touchy bit) c. test and set the no-touchy bit - if das bit is already set, release main semaphore and retry later - else set it and continue d. write out no-touchy bit e. fflush (and sync) to make sure secondary storage is updated f. release main semaphore so other records can be locked g. perform whatever function required the mutual exclusion in the 1st place h. reset the no-touchy bit i. write out bit and record, fflushing and syncing along the way j. lather, rinse, repeat You almost have to use this method, because on most systems the total number of semaphores is fixed and quite small, usually < 100. If the records are stored in shared memory rather than disk, you can leave out the fflush and sync stuff. This algorithm is not original on my part by any means, and neither I nor my employer stand behind it in anyway. Buy the weigh, has anyone noticed lockf (NOT flock) having problems? When I axe for the lock on a file on an NFS file system it never gives it to me, even though I know I'm the only one using the file. Needles two say, this is ultra-irritating. It works fine on local file systems. Glad that you got it made, Mikey Lee Ontek Corp PS: Dear wnl, outlaw those insipid ":-)" smiley faces now! [[ Okay. I won't use that smiley face anymore! (-: --wnl ]] VOX: 1-714-768-0301 UUCP: uunet!ontek!mikey (not sure about that - seems too simple) USPS: 22951 Mill Creek Road, Laguna Hills CA 92653