Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!virtech!cpcahil
From: cpcahil@virtech.uucp (Conor P. Cahill)
Newsgroups: comp.unix.i386
Subject: Re: Two Programming Questions
Keywords: Shared Memory Locking
Message-ID: <1990Aug29.121552.1506@virtech.uucp>
Date: 29 Aug 90 12:15:52 GMT
References: <380@icjapan.uucp> <1990Aug27.230044.13699@virtech.uucp> <1990Aug28.221823.3897@chinet.chi.il.us>
Reply-To: cpcahil@virtech.UUCP (Conor P. Cahill)
Organization: Virtual Technologies Inc., Sterling VA
Lines: 26

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.

A.  I didn't write that.  (be sure you attribute quotes of articles 
    correctly).

>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?

There should be no significant performance problems with doing this (although
you code will have to be careful to implement your semantics).  Locking an
area of the file does not require that the file data area be read from 
disk and therefore will not cause any disk i/o and it doesn't cause
an update to the inode.

-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.,
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170