From cf0ad0b190a433596fdd9fe856f6c3ff0c809e39 Mon Sep 17 00:00:00 2001
From: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Date: Wed, 19 May 2010 08:05:19 -0400
Subject: [PATCH] Process and concurrency started.

---
 06process/process         |  91 ++++++++++++++++++++++++++++++++++
 07concurrency/concurrency | 100 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 191 insertions(+)
 create mode 100644 06process/process
 create mode 100644 07concurrency/concurrency

diff --git a/06process/process b/06process/process
new file mode 100644
index 0000000..e14e5a1
--- /dev/null
+++ b/06process/process
@@ -0,0 +1,91 @@
+%Processes
+%Thadeu Cascardo
+
+# Process Context
+
+* System calls
+* Kernel Stack
+* User space memory access
+* current process
+
+# Interrupts
+
+* May race with a process
+* Usually blocks all other interrupts
+* Must be fast
+
+# Bottom Halves: the old way
+
+* Interrupts would work in the top halves and schedule a bottom half for
+  execution
+* Bottom halves executed with interrupts enabled
+* They were static: drivers could not dynamically create them
+* Only one bottom half could execute at a time, even in SMP systems
+
+# Softirqs: scaling Linux
+
+* They were introduced to put the IRQ handling to scale
+* They are static as well, but two of the softirqs are dedicated to tasklets
+* Tasklets allow drivers to schedule some code for execution dynamically
+
+# Sleeping
+
+* There are many places in the code that will wait for an event
+* Waiting should release the processor to another process: that means that the
+  current process (the waiter) will sleep
+* Sleep is equivalent to scheduling, that is, picking up another process to
+  execute
+* Scheduling another process is prone to races
+
+# Atomic context
+
+* Contexts that cannot sleep or schedule
+* IRQs and softirqs are atomic
+* They cannot access user space
+* They cannot sleep
+
+# Current softirqs
+
+* High priority tasklets
+* Timers
+* Network transmit
+* Network receive
+* Block softirq
+* Block iopoll
+* Low priority tasklets
+* Scheduler
+* High Resolution Timers
+* RCU
+
+# SMP
+
+* Races, races, races
+* BKL
+* Scalable locking is needed
+* SMP-safety is what people are selling and buying
+* Only local IRQs are disabled
+
+# Preemption
+
+* Now, a single CPU may race with itself
+* Different problems, different care and approach
+* Some problems are the same and SMP-safety is now relevant in UP systems
+
+# Disabling IRQs
+
+* local\\_irq\\_disable
+* local\\_irq\\_enable
+* local\\_irq\\_save
+* local\\_irq\\_restore
+
+# Disabling Preemption
+
+* preempt\\_disable
+* preempt\\_enable
+* preempt\\_enable\\_no\\_resched
+
+# SMP functions
+
+* smp\\_processor\\_id
+* get\\_cpu
+* put\\_cpu
diff --git a/07concurrency/concurrency b/07concurrency/concurrency
new file mode 100644
index 0000000..afbd041
--- /dev/null
+++ b/07concurrency/concurrency
@@ -0,0 +1,100 @@
+%Concurrency
+%Thadeu Cascardo
+
+# Races
+
+# Classical increment examples
+
+* Threads are incrementing a counter
+* Thread A reads the counter from memory
+* Thread A is interrupted
+* Thread B reads the counter from memory
+* Thread B increments the counter
+* Thread B saves the counter to memory
+* Thread A executes and now has the wrong value in its registers
+
+# Critical section
+
+In the last example, the section of code that increments the *global*
+counter is a critical section.
+
+# Shared data
+
+The problem in here is sharing data with multiple threads. When sharing,
+we need to serialize the access, that is, only one thread may execute
+the critical section at a time.
+
+# Classical problems
+
+* The Philosophers' Dinner
+* The Barber Shop
+* Consumer and Producer
+
+# Linux historical race handling
+
+* cli/sti
+* BKL
+* semaphores/old mutexes
+* spinlocks
+* RCU
+* new mutexes
+
+# Semaphores and mutexes
+
+# Semaphores
+
+* include linux/semaphore.h
+* kernel/semaphore.c
+* down(sem)
+* up(sem)
+* sema\\_init(sem, val)
+* init\\_MUTEX(sem)
+* init\\_MUTEX\\_LOCKED(sem)
+* DECLARE\\_MUTEX(varname)
+* down\\_interruptible(sem)
+
+# New mutex
+
+* Ingo Molnar's design
+* Documented at Documentation/mutex-design.txt
+
+# How to use the new mutex
+
+* struct mutex
+* mutex\\_init(mtx)
+* DEFINE\\_MUTEX(varname)
+* mutex\\_lock
+* mutex\\_unlock
+
+# When you should or should not use them
+
+* They both sleep, so take care: no atomic contexts
+* When the critical section may sleep
+
+# Spinlocks
+
+* include linux/spinlock.h
+* Documentation/spinlocks.txt
+
+# How to declare them
+
+* DEFINE\\_SPINLOCK
+* spinlock\\_t
+* spin\\_lock\\_init
+
+# How to use them
+
+* spin\\_lock
+* spin\\_unlock
+* spin\\_lock\\_irqsave
+* spin\\_unlock\\_irqrestore
+
+# When you should and should not use them
+
+* They can be used in atomic contexts
+* They lock the processor when "waiting", so use for fast critical
+  sections
+* They create an atomic context themselves, so *do not* sleep while
+  using them
+
+
-- 
2.20.1