1 / 16

Chapter 33. Event-based Concurrency (Advanced)

Chapter 33. Event-based Concurrency (Advanced). Kihyun Cho(choki@snu.ac.kr) School of Computer Science and Engineering Seoul National University. Introduction : Thread vs Event. 1995 - Why Threads are a Bad Idea (for most purposes) John Ousterhout, (UC Berkeley, Sun Labs)

lauriebishop
Télécharger la présentation

Chapter 33. Event-based Concurrency (Advanced)

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. Chapter 33.Event-based Concurrency(Advanced) Kihyun Cho(choki@snu.ac.kr) School of Computer Science and Engineering Seoul National University

  2. Introduction : Thread vs Event • 1995 - Why Threadsare a Bad Idea (for most purposes) • John Ousterhout, (UC Berkeley, Sun Labs) • 2003 - Why Eventsare a Bad Idea (for high-concurrency servers) • R. von Behren, J. Condit, Eric Brewer (UC Berkeley)

  3. Introduction : Why do we need threads? Threads Process address space • To utilize the idle time of the CPU • e.g. Blocking I/O operations • To enhance responsiveness of the system • e.g. GUI system

  4. Introduction : Why threads are bad? “ How to build concurrent servers without threads? ” Source : http://www.redthreadproductions.com/wp-content/uploads/2012/01/WavyThreadImage.jpg Retrieved on 2015/05/27 • Difficult to program • Synchronizing access to shared state • Deadlockrisk • Modules must be designed “thread safe” • Difficult to achieve good performance • Simple locking lowers concurrency • Context switching costs • Difficult to control over scheduling

  5. The basic idea: An event loop Event Loop Event Handlers “ How do we know if a message has arrived? ” Event-based concurrency

  6. API : select The highest-numbered fd in the three sets + 1 Descriptorsaddresses that will be examined the interval that select() should block waiting for a fd to become ready Check whether there is incoming I/O

  7. Simple code “ Why simpler? ” - No locks needed • “ However, what if…. • Open • Read • Write • in event handler? ” “ fd_set ” 0 1 2 3 4 5 6 7 8 …. FD_ZERO FD_SET FD_ISSET

  8. A solution: Asynchronous I/O Blocking Non-blocking Synchronous Asynchronous

  9. I/O models: Synchronous blocking I/O Source : http://www.ibm.com/developerworks/linux/library/l-async/ Retrieved on 2015/05/27

  10. I/O models : Synchronous non-blocking I/O Source : http://www.ibm.com/developerworks/linux/library/l-async/ Retrieved on 2015/05/27

  11. I/O models : Asynchronous blocking I/O Source : http://www.ibm.com/developerworks/linux/library/l-async/ Retrieved on 2015/05/27

  12. I/O models : Asynchronous non-blocking I/O Source : http://www.ibm.com/developerworks/linux/library/l-async/ Retrieved on 2015/05/27

  13. Asynchronous non-blocking I/O (AIO) AIO control block APIs

  14. Asynchronous non-blocking I/O : Sample code • Non-blocking notification • Signal • Callback Source : http://www.ibm.com/developerworks/linux/library/l-async/ Retrieved on 2015/05/27

  15. Why events are bad? • Manual stack management • Can't maintain local state across events • Multiple CPUs system • The synchronization problems arise again • Paging system • If an event-handler page faults, it will block again • Management • Hard to manage over time

  16. Summary • Thread • Why threads are bad? • Event • I/O models • Asynchronous blocking I/O • select • Asynchronous non-blocking I/O • aio • Why events are bad?

More Related