1 / 21

Distributed systems

Distributed systems. Programming with threads. Reviews on OS concepts. Each process occupies a single address space. Reviews on OS concepts. A thread of (execution) control has its own PC counter, stack pointer etc within a process. Thread vs. Process. Why threads?

ipo
Télécharger la présentation

Distributed systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Distributed systems Programming with threads

  2. Reviews on OS concepts • Each process occupies a single address space

  3. Reviews on OS concepts • A thread of (execution) control has its own PC counter, stack pointer etc within a process.

  4. Thread vs. Process • Why threads? • Thread allows running code concurrently within a single process • Switching among threads is light-weight • Sharing data among threads requires no inter-process communication • Why processes? • Fault isolation: One buggy process cannot crash others

  5. Why concurrent programming? • Exploit multiple CPUs (multi-core) • Exploit I/O concurrency • Do some processing while waiting for disk (network, terminals, etc.) • Responsive GUI • Respond to users while doing processing in the background • Reduce latency of networked services • Servers serve multiple requests in parallel • Clients issue multiple requests in parallel

  6. Single threaded servers do not fully utilize I/O and CPU time Network usage time disk usage time CPU usage

  7. Multi-threaded servers achieve I/O concurrency time Network usage time disk usage time CPU usage

  8. Designing a thread interface • Create and manage threads • pthread_create, pthread_exit, pthread_join • Provide mutual exclusion • pthread_mutex_lock, pthread_mutex_unlock • Coordinate among multiple threads • pthread_cond_wait, pthread_cond_signal

  9. Common Pitfalls • Race condition • Deadlock • Better bugs than race • Wrong lock granularity • Leads to race or bad performance! • Starvation

  10. Remote procedure calls

  11. RPC abstraction • Everyone loves procedure calls • Transfer control and data on local programs • RPC goal: make client/server communication look like procedure calls • Easy to write programs with • Procedure calls are a well-understood model • RPC hides details of passing data between nodes

  12. RPC vs. alternatives • Alternatives: • Sockets • MPI • Distributed shared memory (later classes) • Map/Reduce, Dryad (later classes) • RPC is very popular in programming distributed systems • XML RPC • Java RMI • Sun RPC

  13. RPC architecture overview • Servers export their local procedure APIs • On client, RPC library generates RPC requests over network to server • On server, called procedure executes, result returned in RPC response to client

  14. RPC architecture App Server App Client RPC server library RPC client library RPC request rpc call transmit rpc handler marshal args receive marshal args wait work rpc handler return rpc call return unmarshal args unmarshal args receive RPC response transmit

  15. Key challenges of RPC • RPC semantics in the face of • Communication failures • delayed and lost messages • connection resets • expected packets never arrive • Machine failures • Server or client failures • Did server fail before or after processing the request? • Might be impossible to tell communication failures from machine failures

  16. RPC failure semantics • RPC might return “failure” instead of results • What are the possible outcomes in the face of failures? • Procedure did not execute • Procedure executed once • Procedure executed many times • Procedure partially executed • Desired semantics: at-most-once

  17. YFS’s RPC library lock_client lock_server RPC request rpc call transmit rpc handler marshal args receive marshal args wait work rpc handler return rpc call return unmarshal args unmarshal args receive RPC response transmit rpcc rpcs cl->call(lock_protocol::acquire, x, ret) Server.reg(lock_protocol::acquire, &ls, &lock_server::acquire)

  18. RPC semantics • Does yfs rpc implement at-most-once semantics? • How would the lack of at-most-once affect applications?

  19. Interactions between threads and RPCs • Can a client hold locks across RPCs? • Should it do so? client_func() { pthread_mutex_lock(&cl_lock); cl_rpcc->call(….) pthread_mutex_unlock(&cl_lock); }

  20. Interactions between threads and RPC • How about this client side code? client_func() { pthread_lock(&cl_lock); for (vector<rpcc>::iterator i = list.begin(); i != list.end(); i++) { pthread_mutex_unlock(&cl_lock); (*i).call(….) pthread_mutex_lock(&cl_lock); } }

  21. Interactions between threads and RPCs • Can a server make a RPC call during RPC handler?

More Related