nagy%warner.hepnet@LBL.ARPA (09/04/87)
> Hopefully someone can provide some insight into a Real-time application > on a MicroVMS system. I am trying to use mapped global sections for > sharing real-time data and was wondering... I have made extensive uses of mapped global sections in all sorts of ways on 780s/785s and now MicroVAXes. > Has anyone ever used the $CRMPSC system service to associate a > section of process address space with page frame numbers (Map by PFN) > other than the I/O page? I have not been able to determine which > page frame numbers are available for me to use. PFN mapping is only useful for mapping I/O space addresses because VMS is controlling the allocation of the memory page frames. PFN mapping of main memory would only be "useful" to peek into other processes (of dubious value anyway, how do you find another processes pages...). So, since you don't seem to be interested in mapping I/O space, you almost certainly don't want to do PFN mapping. An experimenter here at Fermilab wanted to create a global section which was locked into memory. Mistakenly, he thought to do this by using PFN mapping of pages 0..N, but found that processes would mysteriously abort, the system would mysteriously crash, etc. The reason should now be obvious, he was mapping memory in use by the system and other processes. He then proceeded to write over these pages causing complete and utter chaos. > Basically, I'm trying to is create a permanent physical section of > 450 pages to keep real-time data and then have another process be able > to read the mapped global section (but not modify it). Ok, so we ignore PFN mapping. You still have two choices for your global section. You can map a disk file as a global section or you can just use pages from the page file for your global section. Mapping the disk file is nice because, when the global section is deleted, its contents are written back to the disk file. The disk file thus represents the last values stored in the global section. Using global pages from the page file is easy since one does not have to do the special disk file open needed to map a global section from a file. Below are some code fragments from a set of routines I wrote recently which used a page file global section of 1 page to create a small global section to hold system-wide information (this global section was created in kernel mode since it is only used by kernel-mode user-written system services). P0_SPACE: ;Map section into P0 space .LONG 512, 512 ; ; Make/map system global section ESS_IRA_DESCRS into P0 space from the ; page file. Pages are to be writeable, temporary and initially zero (demand ; zero pages). ; SECTION_NAME: .ASCIC /ESS_IRA_DESCRS/ SECTION_FLAGS: .LONG SEC$M_GBL!SEC$M_SYSGBL!SEC$M_WRT!SEC$M_EXPREG!- SEC$M_DZRO!SEC$M_PAGFIL These flags are set to: - create a global section (SEC$M_GBL) - make it a system-wide global section (SEC$M_SYSGBL) - make it writeable by this process (SEC$M_WRT) - map it into P0 space (the P0_SPACE quadword) by expanding the P0 virtual address space (SEC$M_EXPREG) since I don't care to specify an explicit mapping address. - use pages from the paging file (SEC$M_PAGFIL) - on first reference, the pages should be created filled with zeroes - demand zero pages (SEC$M_DZRO) $CRMPSC_S - ;Create/map section inadr=P0_SPACE,- ;Into P0 space retadr=W^RADSECTION_BASE,- acmode=#PSL$C_KERNEL,- ;Accessible only from kernel mode flags=SECTION_FLAGS,- gsdnam=(R2),- pagcnt=#rad_pages ;Size in pages BLBC R0,99$ ;BR if error $LCKPAG_S - ;Lock RAD pages into memory inadr=W^RADSECTION_BASE,- acmode=#PSL$C_KERNEL BLBC R0,99$ ;BR if error >>> 450 pages to keep real-time data and then have another process be able >>> to read the mapped global section (but not modify it). This is easy, the CREATOR process creates and maps the global section with write access. The EATER process maps the global section w/o write access (leave off the SEC$M_WRT flag). I hope this helps clear up your confusion. = Frank J. Nagy "VAX Guru" = Fermilab Research Division EED/Controls = HEPNET: WARNER::NAGY (43198::NAGY) or FNAL::NAGY (43009::NAGY) = BitNet: NAGY@FNAL = USnail: Fermilab POB 500 MS/220 Batavia, IL 60510