IPC, Threads, Races, Critical Sections Inter-Process Communication - PDF document

4/14/2017 IPC, Threads, Races, Critical Sections Inter-Process Communication 7A. Inter-Process Communication • the exchange of data between processes 3T. Threads • Goals – simplicity 7B. The Critical Section Problem – convenience – generality – efficiency – security/privacy – robustness and reliability • some of these turn out to be contradictory IPC, Threads, Races and Critical Sections 1 IPC, Threads, Races and Critical Sections 2 OS Support For IPC Typical IPC Operations • channel creation and destruction • Wide range of semantics • write/send/put – may appear to be another kind of file – insert data into the channel – may involve very different APIs • read/receive/get • provide more powerful semantics – extract data from the channel • more accurately reflect complex realities • channel content query • Connection establishment mediated by the OS – how much data is currently in the channel – to ensure authentication and authorization • connection establishment and query • Data exchange mediated by the OS – control connection of one channel end to another – to protect processes from one-another – who are end-points, what is status of connections – to ensure data integrity and authenticity IPC, Threads, Races and Critical Sections 3 IPC, Threads, Races and Critical Sections 4 IPC: messages vs streams IPC: flow-control • queued messages consume system resources • streams – buffered in the OS until the receiver asks for them – a continuous stream of bytes • many things can increase required buffer space – read or write few or many bytes at a time – write and read buffer sizes are unrelated – fast sender, non-responsive receiver – stream may contain app-specific record delimiters • must be a way to limit required buffer space • Messages (aka datagrams) – back-pressure: block sender or refuse message – a sequence of distinct messages – receiver side: drop connection or messages – each message has its own length (subject to limits) – this is usually handled by network protocols – message is typically read/written as a unit • mechanisms to report stifle/flush to sender – delivery of a message is typically all-or-nothing IPC, Threads, Races and Critical Sections 5 IPC, Threads, Races and Critical Sections 6 1

4/14/2017 IPC: reliability and robustness Simplicity: pipelines • reliable delivery (e.g. TCP vs UDP) • data flows through a series of programs – networks can lose requests and responses – ls | grep | sort | mail • a sent message may not be processed – macro processor | complier | assembler – receiver invalid, dead, or not responding • When do we tell the sender "OK"? • data is a simple byte stream – queued locally? added to receivers input queue? – buffered in the operating system – receiver has read? receiver has acknowledged? – no need for intermediate temporary files • how persistent is system in attempting to deliver? • there are no security/privacy/trust issues – retransmission, alternate routes, back-up servers, ... – all under control of a single user • do channel/contents survive receiver restarts? • error conditions – can new server instance pick up where the old left off? – input: End of File output: SIGPIPE IPC, Threads, Races and Critical Sections 7 IPC, Threads, Races and Critical Sections 8 Generality: sockets half way: mail boxes, named pipes • connections between addresses/ports • client/server rendezvous point – connect/listen/accept – a name corresponds to a service – lookup: registry, DNS, service discovery protocols – a server awaits client connections • many data options – once open, it may be as simple as a pipe – reliable (TCP) or best effort data-grams (UDP) – streams, messages, remote procedure calls, … – OS may authenticate message sender • complex flow control and error handling • limited fail-over capability – retransmissions, timeouts, node failures – if server dies, another can take its place – possibility of reconnection or fail-over • trust/security/privacy/integrity – but what about in-progress requests? – we have a whole lecture on this subject • client/server must be on same system IPC, Threads, Races and Critical Sections 9 IPC, Threads, Races and Critical Sections 10 Ludicrous Speed – Shared Memory IPC: synchronous and asynchronous • synchronous operations • shared read/write memory segments – writes block until message sent/delivered/received – mmap(2) into multiple address spaces – reads block until a new message is available – perhaps locked in physical memory – easy for programmers, but no parallelism • asynchronous operations – applications maintain circular buffers – writes return when system accepts message – OS is not involved in data transfer • no confirmation of transmission/delivery/reception • simplicity, ease of use … your kidding, right? • requires auxiliary mechanism to learn of errors – reads return promptly if no message available • reliability, security … caveat emptor! • requires auxiliary mechanism to learn of new messages • generality … locals only! • often involves "wait for any of these" operation IPC, Threads, Races and Critical Sections 11 IPC, Threads, Races and Critical Sections 12 2

4/14/2017 a brief history of threads What is a thread? • processes are very expensive • strictly a unit of execution/scheduling – to create: they own resources – each thread has its own stack, PC, registers – to dispatch: they have address spaces • multiple threads can run in a process • different processes are very distinct – they all share the same code and data space – they cannot share the same address space – they all have access to the same resources – they cannot (usually) share resources – this makes the cheaper to create and run • not all programs require strong separation • sharing the CPU between multiple threads – cooperating parallel threads of execution – user level threads (w/voluntary yielding) – all are trusted, part of a single program – scheduled system threads (w/preemption) IPC, Threads, Races and Critical Sections 13 IPC, Threads, Races and Critical Sections 14 When to use processes Using Multiple Processes: cc # shell script to implement the cc command • running multiple distinct programs cpp $1.c | cc1 | ccopt > $1.s • creation/destruction are rare events as $1.s • running agents with distinct privileges ld /lib/crt0.o $1.o /lib/libc.so mv a.out $1 • limited interactions and shared resources rm $1.s $1.o • prevent interference between processes • firewall one from failures of the other IPC, Threads, Races and Critical Sections 15 IPC, Threads, Races and Critical Sections 16 Using Multiple Threads: telnet When to use threads • parallel activities in a single program netfd = get_telnet_connection(host); pthread_create(&tid, NULL, writer, netfd); • frequent creation and destruction reader(netfd); pthread_join(tid, &status); • all can run with same privileges ... • they need to share resources reader( fd ) { int cnt; char buf[100]; while( cnt = read(0, buf, sizeof (buf) > 0 ) • they exchange many messages/signals write(fd, buf, cnt); • no need to protect from each other } writer( fd ) { int cnt; char buf[100]; while( cnt = read(fd, buf, sizeof (buf) > 0 ) write(1, buf, cnt); } IPC, Threads, Races and Critical Sections 17 IPC, Threads, Races and Critical Sections 18 3