jimmy@denwa.info.com (Jim Gottlieb) (08/27/90)
One of our programmers (who happens to be too lazy to get his UUCP link
up and working) asked me to ask the following questions. We use
Interactive 2.2.
He is trying to open a tty port for a read and he wants the read to
time out and complete after a certain time-out period has elapsed. He
says that TFM explains how to do this but it does not work; it never
times out. I suggested that he first try installing the FAS driver,
but he does not want to give up VP/ix access to the serial ports.
He also wonders if there is some way to write-lock shared memory.
Our application requires that no more than one process be altering the
contents of a certain shared memory segment. If not, I guess we can
always kludge around the problem by using the presence of a "lock" file
to indicate whether it is OK to write to that shared memory, or we can
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.
Any hints welcomed. Thanks...
--
Jim Gottlieb Info Connections, Tokyo, Japan
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
<jimmy@pic.ucla.edu> or <jimmy@denwa.info.com> or <attmail!denwa!jimmy>
Fax: +81 3 237 5867 Voice Mail: +81 3 222 8429cpcahil@virtech.uucp (Conor P. Cahill) (08/28/90)
In article <380@icjapan.uucp> jimmy@denwa.info.com (Jim Gottlieb) writes: >time out and complete after a certain time-out period has elapsed. He >says that TFM explains how to do this but it does not work; it never >times out. I suggested that he first try installing the FAS driver, This should work. I would suggest that you post a portion of the code that is having the problem so we can pick it apart. >He also wonders if there is some way to write-lock shared memory. Nope. Like a file descriptor, once you have gotten access to the item, the mode of access cannot be changed. >contents of a certain shared memory segment. If not, I guess we can >always kludge around the problem by using the presence of a "lock" file >to indicate whether it is OK to write to that shared memory, or we can Or you could use a semaphore (or with the right code, use part of the shared memory to set a flag that means you can write to it - Before you people try to jump on this, I know that a simple flag will not work since both processes could check and/or set the flag at the same time. A combination of flags and code is required). >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. While it may be in the block buffer cache, each operation will still require : a) a system call (read/write) b) an inode update c) a search through the buffer cache d) data copying from your user buffer to a system buffer Much less efficient than using shared memory (hence the reason that many, if not all, of the major database manufacturers are using shared memory for database caching, if possible) -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
les@chinet.chi.il.us (Leslie Mikesell) (08/29/90)
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? Les Mikesell les@chinet.chi.il.us
@tree.uucp (Chris Gonnerman) (08/29/90)
In article <1990Aug27.230044.13699@virtech.uucp>, cpcahil@virtech.uucp (Conor P. Cahill) writes: > In article <380@icjapan.uucp> jimmy@denwa.info.com (Jim Gottlieb) writes: [ stuff deleted ] > >contents of a certain shared memory segment. If not, I guess we can > >always kludge around the problem by using the presence of a "lock" file > >to indicate whether it is OK to write to that shared memory, or we can > > Or you could use a semaphore [ text about alternate semaphore implementation deleted ] I have a group of programs which must syncronize access to a pair of shared segments, and I am using message queues. While message queues are not suitable in all cases they seem much simpler when the sharing is on an "in turn" basis... that is, one program writes the segment, then sends a message to the next program which may write the segment, etc. You can even do a sort of "token ring" implementation, although my code uses another setup. It really depends on what you are doing with the segments. Probably your best bet is semaphores, but you need to examine all the possibilities. -- +----------------------------------------------------------------------------+ | Chris Gonnerman (Mad Programmer At Large) csusac.ecs.csus.edu!tree!jcg | | @ the Tree BBS, Sacramento, CA ucbvax!ucdavis!csusac!tree!jcg | +---------- DISCLAIMER: These opinions are mine... MINE, I say! -----------+
cpcahil@virtech.uucp (Conor P. Cahill) (08/29/90)
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
dougp@ico.isc.com (Doug Pintar) (08/30/90)
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