Shared Memory Problem

[John F. Haugh II]

In article <4918 at b-tech.ann-arbor.mi.us> zeeff at b-tech.ann-arbor.mi.us (Jon Zeeff) writes:
>In article <3246 at ucdavis.ucdavis.edu> tuck at iris.ucdavis.edu (Devon Tuck) writes:
>>The closest solution I have found, is to create a host subroutine which
>>passes the buffer array of a program into  shared memory, loads it with the
>>new information, and then returns it.  The problem with this is, the loop
>>which checks for this new information will most probably be an infinite
>>loop,
>
>If I understand your situation correctly, you want several programs to 
>wait on an update of a shared memory segment without sitting in an 
>polling loop.  One way to do this would be to create a fifo (with 
>mknod(1)) for each process and write a byte to each of them when you 
>update the segment.  The other processes can do a blocking read on the 
>fifo.  This is just the first thing that came to mind - there are 
>probably other ways to do this.  

Yes, there are message queues and semaphores.  I suggest messages queues
as being the best mechanism, but that's because I don't like semaphores
anyway ;-)

Have the updating process place messages on the queue for each process
which is to be awoken - or you could signal a semaphore, if you are into
the semaphore idiom.

An amusing solution, for those people with file locking but no shared
memory [ Berzerkeley UNIX folks ] is to create a file to hold all the buffers
and use file locking to insure mutual exclusion.  Hadn't thought of that
solution ...
-- 
John F. Haugh II                        +----Make believe quote of the week----
VoiceNet: (214) 250-3311   Data: -6272  | Nancy Reagan on Richard Stallman:
InterNet: jfh at rpp386.Dallas.TX.US       |          "Just say `Gno'"
UucpNet : <backbone>!killer!rpp386!jfh  +--------------------------------------