From: gezelter@rlgsc.com
Newsgroups: comp.os.vms
Subject: Re: Clustered Global Section
Date: 21 Aug 92 01:04:45 EST
Organization: Robert Gezelter Software Consultant, Flushing, NY

In article <1992Aug19.145551.25308@rdg.dec.com>, winalski@adserv.enet.dec.com (Paul S. Winalski) writes:
> 
> In article <1992Aug19.062727.204@rlgsc.com>, gezelter@rlgsc.com writes:
> |> 
> |>Sorry to be the bearer of bad news, but no, sharing Global 
> |>Sections across a cluster is a very bad solution (It will not 
> |>work).
> |> 
> |>There is literally no way to guarantee the paging behavior of a 
> |>global section in any event (other than open/closing the 
> |>section).
> |> 
> |>A different version of this hazard is also seen in many programs 
> |>which use Global Sections on a single processor. The timing 
> |>hazards which can appear (seemingly out of nowhere) are very 
> |>impressive.
> 
> I beg your pardon, but sharing data using global sections works just fine on
> a single processor, provided you follow the proper programming conventions
> for data sharing between asynchronously running tasks (i.e., protection of
> critical sections), which you have to follow in any event no matter how your
> two independent processes are sharing data.  The above paragraph implies
> that there is some problem with paging behavior in the single-processor case,
> and that simply is not in any way true.  The whole point of global sections
> is to allow multiple processes running on the same system to share data.
> Any timing problems that may occur are self-inflicted and due to sloppy
> programming by the user.
> 
> --PSW
-- 
Paul,
 
You interpreted my post as a stronger statement than was meant. I 
never intended to imply that there were any dangers inherent in 
VMS' implementation of shared global sections.
 
In my consulting practice, I have come across numerous cases 
where programmers got their synchronization and timing 
requirements "almost" correct. For example, I once saw a case 
where an unaligned variable (longword aligned in such a way that 
two fetch operations were required behave in a rather spectacular 
-explosive- fashion). To make things even nastier, many of these 
programs interact in very time critical ways, so that the 
difference between CPU type (or, the question of whether or not 
the page is found in memory or has to be read from disk) makes 
the difference between the code working and not working.
 
These incidents are invariably difficult to localize (often they 
fit in the category of "non reproduceable). Thus, eliminating 
them is often a question of raw effort and some good luck.
 
Because of the stringent requirements that access to critical 
sections be strictly controlled, I generally try to discourage 
the use of global sections in most applications programs. The 
haards of getting it wrong are greater than the savings realized 
in most programs.
 
I hope that the above clarifies the intent of my earlier post.
 
If I have not been clear, please drop me a note.
 
- Bob
+--------------------------------------------------------------------------+
| Robert "Bob" Gezelter                       E-Mail:  gezelter@rlgsc.com  |
| Robert Gezelter Software Consultant         Voice:   +1 718 463 1079     |
| 35-20 167th Street, Suite 215               Fax:       (on Request)      |
| Flushing, New York  11358-1731                                           |
| United States of America                                                 |
+--------------------------------------------------------------------------+
Xref: sparky comp.os.vms:13565 comp.sys.dec:4481 news.software.readers:1623 comp.mail.misc:2637