Initial commit

 The short story:

 Marty Kalin

 Chicago, IL

 kalin@cs.depaul.edu

 http://condor.depaul.edu/mkalin

 Faculty member in computer science for over 30 years at DePaul University

   # College of Computing and Digital Media at DePaul

   # PhD from Northwestern University

   # Written and co-written books about C, C++, and Java

 Real-world programming, as a consultant, concurrent and distributed systems, especially

 in the areas of process planning and scheduling (steel industry), and in product

 configuration (truck/bus manufacturing).

 Like you, I always want to see the code. :)

 Concurrency and parallelism: working technical definitions

      client requests  +------------+   ## Task1: handle request1

    ------------------>| web server |   ## Task2: handle request2

                       +------------+      ...

 ## 1st scenario: a single-processor machine with time-sliced scheduling 

    ### Assume each task is scheduled for a fixed-length time slice, and then is

	    pre-empted and rescheduled if its processing exceeds that time slice.

               Time span (TS) = Start to Finish

Start time                                         Finish time

         |                                         |

         +-----------------------------------------+   ## each star * is one system-clock tick

          \             /\         /\             /

           ****Task1****  **Task2**  ****Task1****     ## Task1 (16 ticks) and Task2 (4 ticks) share the processor

    ### Task1 and Task2 are processed concurrently during time span TS: their processing overlaps during TS.

	#### Task1 and Task2 are not processed in parallel, as there's but a single processor that must be shared.

    ### 1st scenario exhibits concurrency, but not true parallelism.

 ## 2nd scenario: a multi-processor machine (assume two for simplicity)

                 Time span 

Start time                       Finish time

         |                       |

         +-----------------------+

          \                     /

           ********Task1********      ### Executing on processor1

		   \         /

		    **Task2**         ### Executing on processor2

    ### Task1 and Task2 again are processed concurrently (during the same time span TS).

	### Task1 and Task2 also are processed in parallel for a while--for 4 ticks (Task2's processing time).

	### The machine's throughput is improved: Task1 and Task2 both complete within

	    16 time units, the time taken to process Task1, the longer of the two.

        #### 1st scenario requires 20 clock ticks (each 1 time unit) to complete the two tasks.

		#### 2nd scenario requires 16 clock ticks to complete the two tasks, a 20% improvement.

 Concurrency, parallelism, and non-blocking I/O: an overview

 # For now, concurrency is "handling many tasks during the same time span":

   ## Any app with a GUI (e.g., a game) needs to manage the GUI and perform the underlying logic.

   ## A typical network app queues up requests, which then need to be handled concurrently.

 # For now, (true) parallelism is "processing many tasks literally at the same time."

   ## The tasks in a concurrent app would be farmed out to separate processors for true parallelism.

   ## True parallelism requires multiple processors.

      ### Multiprocessor machines now are available at consumer prices.

 # Two 'classic' mechanisms for concurrency: multiprocessing and multithreading.

   ## Each mechanism supports true parallelism on a multiprocessor machine.

 # Non-blocking I/O enables quick jumps from one I/O task to another, thereby supporting

   concurrency without parallelism.

   ## Non-blocking I/O typically is used in conjunction with  a 'classic' approach:

      ### The nginx web server: multiprocessing + non-blocking I/O

      ### Node.js: non-blocking I/O at the API level, multithreading under the hood.

 # Summary

   ## Concurrency is a requirement for many modern apps, and there are various ways to enable it.

   ## Parallelism boosts performance by increasing throughput: more work done in a given amount of time.

      ### Concurrent tasks can be executed in parallel on a multiprocessor machine.

   ## Non-blocking I/O is used mostly in combination with multiprocessing or multithreading

 System call overview for concurrency, parallelism, and non-blocking I/O

 # The systems context: user-space and kernel-space code

   ## User-space code does not control shared physical resources (processors, memory, I/O devices).

      ### Ordinary applications execute in user space.

   ## Kernel-space code comprises the core OS routines that control shared physical resources.

   ## A "system call" originates in user-space, but results in the execution of a kernel-space routine.

      ### Standard library functions (user-space) mediate between ordinary application code and

	  the core OS routines (kernel-space) that some library functions call.

      ### The standard library goes by various names: on Unix-type systems, libc or variants thereof

          (e.g., glibc on Ubuntu); on Windows, the Windows API or variants thereof (e.g., Win32 API)

   ## Depiction: Node.js app calls the cluster.fork() function

                                                               system call

                                                    user space<----+---->kernel space

                                                                   |

               calls                 calls                         | calls

   Node.js app------->cluster.fork()------->library function fork()|------->kernel routine 

                                                                   |     ## in traditional Unix, named fork

                                                                   |     ## in modern Linux, named clone

 # How many library functions make system calls?

   ## Not every library function makes a system call, e.g., strlen("foobar") does not.

   ## Of the 2,000 or so library functions, about 400 result in system calls.

 # Back to an earlier question: Why C?

    The standard libraries and kernel routines are written mostly in C, with some assembly language or

    non-standard C extensions covering the rest.

 Wrapup of the overview

 # Concurrency and parallelism are different.

   ## Concurrency involves handling multiple tasks in the same time span.

   ## Parallelism involves processing multiple tasks literally at the same time.

      ### True parallelism requires multiple processors.

   ## Parallelism is a performance-boosting way to manage concurrency.

 # The classic approaches to concurrency are multiprocessing and multithreading.

   ## Non-blocking I/O has emerged as an option as well, but one that's typically

      used in conjunction with multiprocessing or multithreading.

   ## Non-blocking I/O sometimes is described as 'concurrency without parallelism'.

 # Different languages have difference advantages when it comes to studying

   concurrency, parallelism, and non-blocking I/O.

   ## C is close to the metal: the system libraries and core OS routines at work under the hood.

   ## Whatever the application language, multiprocessing, multithreading, and non-blocking I/O

      calls in the language hit the C libraries and, from there, kernel-space routines.

   ## Java (C#), Go, Node.js and other languages have particular styles and strengths

      with respect to concurrency in particular.