From: Renison, Rick (rick.renison@EDS.COM)
Date: Fri Nov 22 2002 - 16:16:52 EST
Use semaphores for locking. They are atomic routines. They will keep
processes from clobbering each other.
Don't assume a move such as int a=1; will work, since this a 2 byte move.
Another process that tries a a=-1; could have conflicts... eg. you could
end up with a value of x'FF01'.... not what you expect.
Always lock before changing OR accessing the values.
These code samples should help you. I just reserve the first word of shared
memory to be the location where the semaphore id is stored.
void blk_lock (
pointer pool) /* pool to lock from */
{
struct sembuf sop_lock[2] = { /* for semaphore operations */
0, 0, 0, /*wait for sem to become zero */
0, 1, SEM_UNDO }; /* then increment by one */
/*+ lock the block (after waiting for it to clear) -*/
semop( ((struct sfeshmc *)pool)->_semid, &sop_lock[0], 2);
return;
}
void blk_unlock (
pointer pool) /* pool to unlock from */
{
struct sembuf sop_unlock[1] = { /* for semaphore operations
*/
0, -1, (SEM_UNDO | IPC_NOWAIT) };
/*+ unlock the lock -*/
semop( ((struct sfeshmc *)pool)->_w_semid, &sop_unlock[0], 1);
}
Rick Renison
EDS Canada
> -----Original Message-----
> From: Bruce Harvey [mailto:BruceH@ROUTESCAPE.COM]
> Sent: November 21, 2002 3:22 PM
> To: aix-l@Princeton.EDU
> Subject: Re: SHM primer?
>
>
> Here is a link to IPC
> http://www.ibiblio.org/mdw/LDP/lpg/node21.html
> and a link to shared memory
>
> http://www.ibiblio.org/mdw/LDP/lpg/node65.html#SECTION00744000
> 000000000000
> or
> http://www.ecst.csuchico.edu/~beej/guide/ipc/shmem.html
>
> In any event, shared memory is vital for certain
> multi-process programs to
> get their work done. The problem with corrupted shared
> memory arrives when
> they don't have a GOOD method for managing who's allowed to
> write to the
> memory when. Semaphores are sometimes used (another IPC), as
> are message
> queues, but most often, the shared memory itself contains areas where
> processes will place their process ids, "locking" a memory
> region for their
> use. However, if two processes write their ids at about the
> same time, they
> each may think they own it, so there needs to be a reliable 'retry'
> 'recheck' and so forth method to absolutely guarantee no one
> else is writing
> when you are. For example, you write your id, wait a second,
> then read it.
> If it's changed, you wait a given time and so forth. Or you
> pass around a
> key like token ring does. Or you Message or semaphore.
>
> Ever wonder why UUCP just about never has any conflicts? See
> if you can
> find code outlining exactly what it does to restrict access
> to a port that's
> in use (lock files that really work).
>
> ---------------------------------------
> Bruce T. Harvey, Special Projects Developer
> bruceh@routescape.com, www.routescape.com
> Insight Distribution Systems --- Hunt Valley, MD
>
>
>
>
> -----Original Message-----
> From: Webb, Eric [mailto:EWebb@COOPERLIGHTING.COM]
> Sent: Thursday, November 21, 2002 3:06 PM
> To: aix-l@Princeton.EDU
> Subject: [aix-l] SHM primer?
>
>
> Do we have any programmer-types out there that could point me in the
> direction of a shared memory primer from a programmer's
> perspective? I'd
> like to know what it is, how it's used, etc. Something from a C/C++
> background would be good.
>
> One of our applications here seems to use it rather
> extensively, and most of
> the quirks we see with it seem to be rooted in shared memory
> corruption.
>
>
> > Eric C. Webb
> > Sr. Systems Analyst / AIX System Administrator
> >
> > Cooper Lighting Division IT
> > (770) 486-4623 (770) 486-4677 FAX
> >
>
>
> This Email and any files transmitted with it are confidential
> and intended
> solely for the use of the individual or entity to whom they
> are addressed.
> If you have received this Email in error please notify the
> system manager.
> Please note that any views or opinions presented in this
> Email are solely
> those of the author and do not necessarily represent those of
> the company.
> Finally, the recipient should check this Email and any
> attachments for the
> presence of viruses. The company accepts no liability for any
> damage caused
> by any virus transmitted by this Email.
>
This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 22:16:22 EDT