1. CGS 3763 Operating Systems Concepts Spring 2013 Dan C. Marinescu Office: HEC 304 Office hours: M-Wd 11:30 - 12:30 AM

2. Last time:  Stubs  Client-server systems  Thin clients  Examples of client-server systems: event service, email, X-windows, Web Today:  Heterogeneity  Remote procedure call  Threads Next time  Threads  Shared memory Reading assignments  Chapter 4 of the textbook  Chapters 4 textbook slides Lecture 16 – Wednesday, February 13, 2013 2Lecture 16

3. 3Lecture 15

4. Client server interactions in HTTP Lecture 154

5. 5 Heterogeneity The client and the service may run on systems with different:  internal data representation, e.g., big versus little endian  processor architecture, e.g., 32 bit /64 bit addressing  operating systems, e.g., version of Linux, Mac OS, etc.  libraries Multiple clients and services provided/available on systems with different characteristics :  the same service may be provided by multiple systems;  a service may in turn user services available on other systems;  the same client may use multiple services. Marshaling/unmarshaling  conversion of the information in a message into a canonical representation and back Lecture 16

6. 6 Little-endian and big-endian Lecture 16

7. 7 Timing; response time The client and the service are connected via communication channel. The response time is a function of the latency and the bandwidth of the communication channel. Distinguish between  service time  communication time Synchronous call  the client blocks waiting for the response. Easier to manage. Asynchronous calls  the client does not block. Multi-threading and asynchronous calls. Message buffering  in kernel space (to allow clients to make asynchronous calls)  in user space (before sending) Lecture 16

8. 8 8 Peer-to-peer systems Decentralized architecture without a trusted intermediary. Peers are both suppliers and consumers of resources, in contrast to the traditional client-server model where servers supply, and clients consume. Peer-to-peer systems often implement an Application Layer overlay network on top of the native or physical network topology. Such overlays are used for indexing and peer discovery. Content is typically exchanged directly over the underlying IP network. Anonymous peer-to-peer systems implement extra routing layers to obscure the identity of the source or destination of queries. In structured peer-to-peer networks, connections in the overlay are fixed. They typically use distributed hash table-based (DHT) indexing, such as in the Chord system developed at MIT Unstructured peer-to-peer networks do not provide any algorithm for organization or optimization of network connections. Advantages   use of spare resources at many sites  difficult to censor content Disadvantage  Finding information in a large peer-to-peer network is hard. Lecture 16

9. 9 9 Remote procedure call (RPC) Support inter-process communication of remotely located processes and allows implementation of client-server systems (RFC 1831) Preserve the semantics of a local procedure call. To use an RPC a process may use a special service: PORTMAP or RPCBIND available at port 111. A new RPC service uses the portmapper to register. The portmapper also allows a service lookup. If the process knows the port number of the RPC it may call directly. RPC/TCP and also RPC/UDP Messages  must be well-structured; contain the identification of the specific RPC  are addressed to an RPC demon listening at an RPC port. A machine independent representation of data  external data representation standard (XDR). Lecture 16

10. 10 Stub Unburdens a user from implementation details of the RPC; it hides:  the marshalling of the arguments  the communication details The client calls the client stub which: 1. marshals the arguments of the call into messages 2. sends the message 3. waits for the responds 4. when the response arrives it un-marshals the results 5. returns to the client Lecture 16

11. 11 Lecture 16

12. 12 RPCs differ from ordinary procedure calls RPCs  reduce the so called fate sharing between caller and callee  have a different semantics (see next slide)  take longer  global variables and RPC do not mix well Lecture 16

13. 13 RPC semantics At least once  the client stub resends a message up to a given number of times until it receives a message from the server; is no guarantee of a response  the server may end up executing the a request more than once  suitable for side-effect free operations At most once  a message is acted upon at most once.  If the timeout set for receiving the response expires then an error code is delivered to the client.  The server must keep a history of the time-stamps of all messages. Messages may arrive out of order…..  Suitable for operations which have side effects Exactly once  implement the at most once and request an acknowledgment from the server. Lecture 16

14. Threads Thread  the smallest sequence of programmed instructions that can be managed independently by an operating system scheduler  a light-weight process  multiple threads can share the same address space On a single processor, multithreading generally occurs by time- division multiplexing, the processorswitches between different threads. This context switching generally happens frequently enough that the user perceives the threads or tasks as running at the same time.processor On a multiprocessor or a multi-core system the threads actually run at the same time, with each processor or core running a particular thread or task. Lecture 1614

15. Single- and multi-threaded processes Lecture 1615

16. Reasons for multithreading Reduce the execution time of a compute-intensive task. Better resource utilization – recall the imbalance between the CPU, memory, and I/O device bandwidth/speed. Improve scalability Example: multithreaded execution on a two core system Lecture 1616

17. Challenges Identify activities that can run in parallel. Divide the workload among the threads and balance the load. Minimize the communication among threads. Avoid barrier-synchronization  instances when all threads have to wait until all of them reach a certain execution stage. Debugging. Lecture 1617

18. Multithreading and client-server systems Lecture 1618

19. User and kernel threads User threads- thread management done by user-level threads library  POSIX Pthreads  Win32 threads  Java threads Kernel threads  Windows XP/2000  Solaris  Linux  Tru64 UNIX  Mac OS X Recall that the kernel has to keep track of all processes on the system and uses the PCB to do that. The kernel has to keep track of al threads as well. Lecture 1619

20. Relations between user and kernel threads Many-to-One  several user-level threads mapped to single kernel thread:  Solaris Green Threads  GNU Portable Threads One-to-One  each user-level thread maps to kernel thread:  Windows NT/XP/2000  Linux  Solaris 9 and later Many-to many  many user level threads mapped to many kernel threads  Allows the operating system to create a sufficient number of kernel threads  Solaris prior to version 9  Windows NT/2000 with the ThreadFiber package Lecture 1620

21. Lecture 1621