Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!ncar!ico!dougp
From: dougp@ico.isc.com (Doug Pintar)
Newsgroups: comp.unix.i386
Subject: Re: Two Programming Questions
Keywords: Shared Memory Locking
Message-ID: <1990Aug29.172857.11051@ico.isc.com>
Date: 29 Aug 90 17:28:57 GMT
References: <380@icjapan.uucp> <1990Aug27.230044.13699@virtech.uucp> <1990Aug28.221823.3897@chinet.chi.il.us>
Reply-To: dougp@ico.ISC.COM (Doug Pintar)
Organization: Interactive Systems Corp., Boulder CO
Lines: 23

In article <1990Aug28.221823.3897@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes:
>In article <1990Aug27.230044.13699@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes:
>
>>>just forget about using shared memory and use a real file with file
>>>locking instead.  If it is being constantly accessed, it will be in
>>>memory anyway.
>
>I've considered opening a real file mapped against the shared memory
>just to be able to use the file locking routines to arbitrate
>access (i.e. lock the file region but access the memory segment
>instead).  Does anyone know how this would work performance-wise
>compared to any reasonable alternatives?

I'm doing this on a large database application I'm building.  The shared mem
databases get initialized from disk files and rewritten when the application
shuts down (with a journal file going to both disk and tape in case it DOESN'T
get shut down!).  I just leave the files open and use lock/unlock on them to
arbitrate access to the shared mem.  Works fine, but it isn't the quickest
operation in the world.  I tend to just lock the heads of lists I'm going to
search rather than each individual item, for example.  I ran a test on a
386/25 (cache) system, and each lock/unlock pair (assuming no conflicts) takes
about 360 microseconds.
DLP