From abg@SEI.CMU.EDU Sat Sep 7 19:57:43 1996 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA12789; Sat, 7 Sep 96 19:57:43 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by inmet.camb.inmet.com (4.1/SMI-4.1) id AA04690; Sat, 7 Sep 96 19:57:58 EDT Received: from dc.sei.cmu.edu by sw-eng.falls-church.va.us (8.7.1/) id XAA12793; Sat, 7 Sep 1996 23:56:06 GMT Received: from localhost.sei.cmu.edu by dc.sei.cmu.edu (8.6.10/3.00) id TAA22106; Sat, 7 Sep 1996 19:59:37 -0400 Message-Id: <199609072359.TAA22106@dc.sei.cmu.edu> To: ada-comment@sw-eng.falls-church.va.us Subject: Shared variables in shared passive packages Date: Sat, 07 Sep 96 19:59:36 EDT From: Anthony Gargaro !topic Shared Variables in Shared_Passive? !reference RM95-9.10, RM95-E.2.1 !reference 96-5647.a Laurent Guerby 96-8-23 !reference 96-5649.a Anthony Gargaro 96-8-24 !reference 96-5656.a Robert A Duff 96-8-27 !keywords synchronization !reference 96-5650.a Robert Dewar 96-8-25 !reference 96-5658.a Robert Dewar 96-8-28 !reference 96-5662.a Robert A Duff 96-8-29 !reference 96-5666.a Robert Dewar 96-8-30 !reference 96-5673.a Anthony Gargaro 96-9-1 !reference as: 96-5674.a Robert Dewar 96-9-2 !reference as: 96-5679.a Anthony Gargaro !reference as: 96-5682.a Robert Dewar 96-9-4 !from Anthony Gargaro 96-9-7 <> !discussion >Robert notes: >I am completely puzzled by Anthony's reaction here. If the only shared >data that is available is protected objects, then that means the only >interface to such data is via a procedural interface. But in this case, >shared passive partitions provide ZERO functionality, since of course >the normal RPC mechanism can perfectly well provide an absolutely >identical interface. The advantage of using a protected object in a shared passive partition over using the remote call capability is that it avoids the overhead of a remote call which at a minimum requires marshaling/unmarshaling. Furthermore, as is mentioned in subsequent comments, using remote calls to support shared variables still requires that the calls be synchronized. >After all the language allows non-protected variables to appear in shared >passive partitions? Why? Was this simply a careless mistake? Given Anthony's >viewpoint, it is always erroneous to place a non-protected variable in >a shared passive partition, so clearly they should not be allowed if that >is really your viewpoint. It should be recalled that one important aspect in specifying Annex E was to balance functionality with implementation cost. The issue of non-protected variables was discussed at the IRTAW-6 (Ravenscar 92, were you not present) and the sentiment was that requiring support beyond that provided by protected objects and pragma Atomic might be unacceptable to implementors. (Note that at the time Annex E required that Annex C be supported.) >Shared data means to me data that can be shared directly. In the case of the example that you presented in an earlier comment, i.e., a single one-time writer partition and multiple reader partitions, this can be achieved. Consider the case that the writer allocates and writes to the variable using a protected object. Readers may then obtain the access value to the variable using the same protected object so that subsequent reads are made using this access value. >To me this is a major hole in the language, and one of two things should be >done. Either completely remove passive partitions from the language, on the >grounds that they are misleading and provide no functionality, or fix them >so that they do provide shared data. The first position seems too extreme. A possible compromise is to provide a documentation requirement where an implementation must state whether or not access to a non-protected variable is erroneous. >This is not only an issue of expressive power, but also of efficiency. The >requirement that any access to shared data be via protected objects means >that you have all the overhead (typically significant when operating over >an operating system, as will usually be the case with distributed >applications) of protected objects, making this feature useless for efficient >interchange of data. I do not understand why you seem to presume that using a protected object declared in a shared passive package is any less efficient than using a protected object declared elsewhere. Why would there be a difference in efficiency? It seems that only when an implementation supports some form of distributed shared virtual memory does this become an efficiency issue. >As I said before, the issue is largely academic, since it is obvious that >convenient access to shared memory is an important requirement, and certainly >in GNAT we will implement it regardless, so what we are discussing is whether >this should be a required part of Annex E functionality or not. It would be helpful if you would suggest the proposed change that does not preclude the GNAT implementation. If this is an instance of where the implementors believe that the Annex is too conservative, it would be a very appropriate topic for discussion at the next IRTAW.