09-Linking and Sharing

1 .Operating Systems 1 9. Linking and Sharing 9.1 Single-Copy Sharing Why Share Requirements for Sharing Linking and Sharing 9.2 Sharing in Systems without Virtual Memory 9.3 Sharing in Paging Systems Sharing of Data Sharing of Code 9.3 Sharing in Segmented Systems

2 .Operating Systems 2 Single-Copy Sharing Focus: sharing a single copy of code or data in memory Why share? Processes need to access common data p roducer/consumer, task pools, file directories Better utilization of memory code, system tables, data bases

3 .Operating Systems 3 Linking and Sharing Linking resolves external references Sharing links the same copy of a module into two or more address spaces Static linking/sharing: Resolve references before execution starts Dynamic linking/sharing: While executing

4 .Operating Systems 4 Sharing without Virtual Memory With one or no Relocation Register (RR) All memory of a process is contiguous Sharing user programs: Possible only with 2 user programs by partial overlap Too restrictive and difficult; generally not used Sharing system components: Components are assigned specific, agreed-upon starting positions Linker resolves references to those locations

5 .Operating Systems 5 Sharing without Virtual Memory With multiple RRs CBR : Code Base Points to shared copy of code SBR : Stack Base Points to private copy of stack DBR : Data Base Points to private copy of data Multiple processes can share code or data

6 .Operating Systems 6 Sharing in Paging Systems Sharing of data pages: PT entries of different processes point to same pages If shared pages contain no addresses , linker can: a ssign arbitrary page numbers to shared pages r ecord in PT So shared data page can have a different page # in different processes But address in shared page does not work

7 .Sharing in Paging Systems Sharing of code pages Solution 1: assign the same page numbers to all shared pages Restrictive Solution 2: no page numbers in shared code Compile self-references relative to CBR Compile data/stack references relative to DBR/SBR Limitation: shared code cannot contain any external references Operating Systems 7

8 .Operating Systems 8 Sharing of Code Pages in Paging Systems When to resolve external references (to shared pages)? loader could check which shared pages are resident, adjust PT (e.g. n2) too much overhead m any shared libs are never accessed solution: defer linking until first access: dynamic linking using transfer vector

9 .Operating Systems 9 Dynamic Linking via Transfer Vector One tv entry per shared module Initially each entry contains only a stub Stub does the following: c hecks if referenced code is loaded i f not, it loads it i t then replaces itself by a branch to shared code Next reference to the same code bypasses stub (simple indirect branch)

10 .Operating Systems 10 Sharing in Segmented Systems Similar to paging Data pages: assign any segment numbers Code pages: Assign same segment numbers in all STs, or Use base registers for self/data/stack references Limitation: no addresses in shared segments But segments are logical entities—permit general solution: Keep private linkage section (LS) for each segment External references are in LS , not in code Every process has its own copy of LS: Can use different segment numbers Introduced in Multics (1968)

11 .Operating Systems 11 Unrestricted Dynamic Linking/Sharing Self -references resolved using CBR Other references via addresses but kept in private LS sharing is unrestricted (can use different page #s, shared segments can contain external references) Linking/sharing is dynamic External reference kept symbolic: (S,W) , where S is a program name and W is a label, e.g. ( H elloWorld , start) At runtime, on first use : ( S,W) is resolved to ( s,w ) , using trap mechanism ( s,w ) is entered in linkage section of process c ode is unchanged Subsequent references use ( s,w ) without involving OS

12 .Operating Systems 12 Dynamic Linking/Sharing Before and After External Reference is Executed