home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / cplus / 20041 < prev    next >
Encoding:
Text File  |  1993-01-28  |  2.8 KB  |  57 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!munnari.oz.au!sgiblab!spool.mu.edu!howland.reston.ans.net!usc!cs.utexas.edu!hermes.chpc.utexas.edu!news.utdallas.edu!corpgate!crchh327!bnr.ca!dgg
  3. From: dgg@bnr.ca (Gordon Grimes)
  4. Subject: Re: Objects in Shared Memory
  5. Sender: news@news.rich.bnr.ca (news server)
  6. Message-ID: <C1HM7B.Gnt@news.rich.bnr.ca>
  7. Date: Wed, 27 Jan 1993 00:47:35 GMT
  8. References: <19930125.084616.825@almaden.ibm.com> <1993Jan25.105459.4799@hellgate.utah.edu>
  9. Nntp-Posting-Host: 131.253.206.67
  10. Organization: BNR
  11. Lines: 44
  12.  
  13. In article <1993Jan25.105459.4799@hellgate.utah.edu>, clark%asylum.cs.utah.edu@cs.utah.edu (Charles Clark) writes:
  14. |> In article <19930125.084616.825@almaden.ibm.com> jimi@vnet.ibm.com (Jim Meyers) writes:
  15. |> >>
  16. |> >>The first of these approaches is not complete in that it does not
  17. |> >>address the problem of intra-object references.  Thus, virtual base classes
  18. |> >>can not be used in the inheritance hierarchy of the shared objects.
  19. |> >
  20. |> >This is not all clear to me... Can you elaborate on why you believe that
  21. |> >Jordan's method does not support intra-object references?
  22. |> 
  23. |> After reviewing Jordan's paper, I see that intra-object references will
  24. |> resolve correctly (Jim, thanks for pointing this out).  His method 
  25. |> requires that, not only the location of the vtable be coordinated, but 
  26. |> also the location of the shared memory segment be coordinated.  This means 
  27. |> that each process which accesses the shared memory segment must attach 
  28. |> that memory segment at the same virtual memory address.  With the memory 
  29. |> segment at the same vm address, the intra-object references will resolve 
  30. |> correctly.  
  31. |> 
  32. |> Straying from the orignal subject a little, how can the location of the 
  33. |> shared memory segments be coordinated?  The vtable location is fixed at 
  34. |> link edit time, thus one would know then whether there is a conflict. 
  35. |> Since the creation and attachment of the shared memory segment is at run-
  36. |> time, how can one ensure that the vm address of each of the cooperating
  37. |> processes will be available?
  38. |> 
  39. |>     --Charles
  40. |> 
  41.  
  42. Some operating systems (HPUX-8.0, for instance) reserve specific virual
  43. addresses for shared memory segments.  As I recall, the manual implies
  44. that each shmem area has its *own* predetermined segment.  This would
  45. suggest that attaching the same shmem area in two processes gaurentees
  46. their identical mapping.
  47.  
  48. I could understand the reasons for an OS to go halfway: start allocating
  49. virtual addresses from, say, 0xc0000000 upward for attached segments, but
  50. not promise that shmem area "A" will map to the exact same virtual address
  51. in two process.  If one is working on such an OS the workaround is to
  52. programmatically ensure that both processes attach the areas in the same
  53. order.
  54.  
  55. Gordon Grimes
  56. Bell Northern Research
  57.