From: Rick Cadruvi [rick@rdperf.com]
Sent: Tuesday, October 30, 2001 3:27 AM
To: Info-VAX@Mvb.Saic.Com
Subject: Re: Global Sections for IPC - performance

I've done the Global section approach and if done correctly, it is by far
the fastest method.
Here's one of the tricks for flipping quickly back and forth between
processes during your
"SPIN" operations.

static void giveup_scheduler_krnl ()
   {
   softint (IPL$_SCHED); \
   }

  main ()
   {
...
   sys$cmkrnl (giveup_scheduler_krnl, 0);
   }

A similar technique on Windows using "Sleep (0);" works REALLY well.

Rick Cadruvi...

"Hoff Hoffman" <hoffman@xdelta.zko.dec.nospam> wrote in message
news:mvjD7.1080$RL6.15040@news.cpqcorp.net...
> In article <3bdd281f.5550050@news.force9.net>, mark@*NO*SPAM*.co.uk (Mark
Williams) writes:
>
>   OpenVMS platform and version?
>
> :We use global sections for IPC between separate processes and have
> :noticed that it is now slower than the old mailbox solution.
>
>   I'd look at ICC or similar, and -- having used both approaches -- I'd
>   get out of the business and the effort of writing and supporting your
>   own communications.
>
> :Can anyone suggest any ideas for checking/optimizing the performance?
>
>   Walk the whole code path with the debugger, and see what the code is
>   really doing.
>
> :Also is there a big overhead in mapping a global section?
>
>   There is certainly some overhead, but I do not know if will prove to be
>   significant in your environment.
>
>   Once mapped, global sections are the fastest communications mechanism
>   available.  Notifications and such can suffer, as there is no "door
>   bell" or associated mechanism -- you have to spin (which has its own
>   problems) or you have to use doorbell locks, event flags, or other
>   interprocess-capable notification mechanism(s).
>
> :At the moment some mappings are done when needed.  Could it be better to
> :do all the mappings on start-up?
>
>   Caching work ahead of when it is needed is usually better, though you
>   could run into virtual addressing limits or paging -- depending on how
>   much data you load.
>
>   Profile your code using PCA (part of DECset), PC sampling, insertion
>   of timing calls within the code, or other similar technique.  And
>   really look and see what your code is doing -- I've learned much by
>   the simple expedient of integrating logging and debugging mechanisms
>   into any complex applications.  With a communications mechanism, this
>   is vital -- having written these, the author of the communications
>   mechanism will often get blamed for most every application bug lurking
>   in the system.  Occasionally, even correctly blamed.  The logging and
>   the integrated debugging was central at resolving these problems.
>
>
>  ---------------------------- #include
<rtfaq.h> -----------------------------
>       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com
>  --------------------------- pure personal
opinion ---------------------------
>    Hoff (Stephen) Hoffman   OpenVMS Engineering
hoffman#xdelta.zko.dec.com
>