Windows Internals

Module 1: Introduction
Pavel Yosifovich
CTO, CodeValue
[email protected]
http://blogs.Microsoft.co.il/blogs/pavely
 Contents

 Course Objectives
 Windows Versions
 Tools
 Summary
 Course Objectives

 Understand Windows features and architecture

 Uncover internal mechanisms relevant for developers
 Enhance ability to write better software for Windows
 Windows Versions

 Windows NT 3.1 (July 1993)

 Windows NT 3.5 (September 1994)
 Windows NT 3.51 (May 1995)
 Windows NT 4.0 (July 1996)
 Windows 2000 (December 1999)
 Windows XP (August 2001)
 Windows Server 2003 (March 2003)
 Windows Vista (January 2007)
 Windows Server 2008 (February 2008)
 Windows 7 & 2008 R2 (October 2009)
 Windows 8 & Windows Server 2012 (October 2012)
 Windows 8.1 (“Blue”) (expected August 2013)
 Tools

 Windows built in
 Task manager, resource monitor, performance monitor, others
 SysInternals
 Obtained from http://www.sysinternals.com (which is redirected to
http://microsoft.technet.com/sysinternals)
 Most written by Mark Russinovich
 No installation needed
 Free
 Debugging tools for Windows
 Now part of the Windows SDK
 No installation needed
 Free
Demo

Getting the tools

 Summary

 Windows has maintained roughly the same architecture

since the first Windows NT version
 Various tools will be used throughout the course to
demonstrate Windows features and behaviors
 Windows Internals
Module 2: Basic Concepts
Pavel Yosifovich
CTO, CodeValue
[email protected]
http://blogs.Microsoft.co.il/blogs/pavely
 Contents

 User mode vs. kernel mode

 Processes
 Threads
 Virtual memory
 Objects and handles
 Summary
 User mode vs. kernel mode

 Thread access mode

 User mode
 Allows access to non-operating system code & data only
 No access to the hardware
 Protects user applications from crashing the system
 Kernel mode
 Privileged mode for use by the kernel and device drivers only
 Allows access to all system resources
 Can potentially crash the system
 Processes

 Process
 A set of resources used to execute a program
 A process consists of
 A private virtual address space
 An executable program, referring to an image file on disk which
contains the initial code and data to be executed
 A table of handles to various kernel objects
 A security context (access token), used for security checks when
accessing shared resources
 One or more threads that execute code
Demo

Task Manager
Demo

Process Explorer
 Threads

 Thread
 Entity that is scheduled by the kernel to execute code
 A thread contains
 The state of CPU registers
 Current access mode (user mode or kernel mode)
 Two stacks, one in user space and one in kernel space
 A private storage area, called Thread Local Storage (TLS)
 Optional security token
 Optional message queue and Windows the thread creates
 A priority, used in thread scheduling
 A state: running, ready, waiting
Demo

Threads
 Virtual Memory

 Each process “sees” a flat linear memory

 Internally, virtual memory may be mapped to physical
memory, but may also be stored on disk
 Processes access memory regardless of where it actually
resides
 The memory manager handles mapping of virtual to physical pages
 Processes cannot (and need not) know the actual physical address of
a given address in virtual memory
 Virtual Memory Mapping
Virtual memory Virtual memory
Physical memory

Process A Process B

Disk
 Virtual Memory Layout

x86 (32 bit) x64 (64 bit)

High addresses

2 GB 6657 GB
System Space System Space

Unmapped

2 GB 8192 GB
User Process (8 TB)
Space User Process
Low addresses Space
Demo

Virtual Memory
 Objects and Handles

 Objects are runtime instances of static structures

 Examples: process, mutex, event, desktop, file
 Reside in system memory space
 Kernel code can obtain direct pointer to an object
 User mode code can only obtain a handle to an object
 Shields user code from directly accessing an object
 Objects are reference counted
 The Object Manager is the entity responsible for creating,
obtaining and otherwise manipulating objects
Demo

Objects and handles

 Summary

 A process is a management container for threads to

execute code
 A Thread executes code on a CPU
 Multiple threads can execute concurrently on multiple
CPUs
 Per process virtual memory provides a private address
space isolated from other processes
 Kernel objects are accessed from user mode using private
process handles
 Windows Internals
Module 3: System Architecture (Part 1)
Pavel Yosifovich
CTO, CodeValue
[email protected]
http://blogs.Microsoft.co.il/blogs/pavely
 Contents

 Windows design goals

 Windows editions
 General architecture overview
 Function call flow
 Summary
 Windows Design Goals

 Separate address space per process

 One process cannot (easily) corrupt another’s memory
 Protected kernel
 User mode applications cannot crash kernel
 Preemptive multitasking and multithreading
 Multiprocessing support
 Internationalization support using Unicode
 Security throughout the system
 Integrated networking
 Windows Design Goals (2)

 Powerful file system (NTFS)

 Supports protection, compression and encryption
 Run most 16 bit Windows and DOS apps
 On 32 bit systems
 Run POSIX 1003.1 and OS/2 applications
 Portable across processors and platforms
 Be a great client as well as server platform
Demo

Unicode in the Windows API

 Windows Editions

 Windows XP Home
 Designed as a replacement for the Windows 9x/ME family
(“Consumer Windows”)
 Windows Professional (2000, XP, Vista, 7, 8)
 Main desktop (client) OS
 Windows Server Standard, Advanced, Datacenter
editions (Windows 2000, 2003/R2, 2008/R2, 2012)
 Server platforms
 Other variants
 XP starter, XP Home, Media center, Server Web Edition, Home,
Premium, Ultimate, Business, Enterprise
 Professional vs. Server

 Same core system files

 Differences
 Number of processors supported
 Maximum amount of RAM than can be used
 Maximum of concurrent network connections supported for file and print
sharing
 Some services only appear in Server versions
 Other system policies and default settings (e.g. thread quantum)
 OS type can be discovered by calling GetVersionEx (Win32) or
RtlGetVersion(WDK)
 Windows Numeric Versions

 Windows NT 4 (4.0)
 Windows 2000 (5.0)
 Windows XP (5.1)
 Windows Server 2003, 2003 R2 (5.2)
 Windows Vista, Server 2008 (6.0)
 Windows 7, Server 2008 R2 (6.1)
 Windows 8, Server 2012 (6.2)
 Windows 8.1, Server 2012 R2 (6.3)
 These values can be obtained using GetVersionEx (Win32) or
RtlGetVersion (WDK)
Demo

Looking at a Windows version

 General Architecture Overview

Environment
Services User Applications
System Subsystem
Processes
Subsystem DLLs

NTDLL.DLL
User Mode

Kernel Mode
Executive
Graphics
(Win32k) Device Drivers Kernel

Hardware Abstraction Layer (HAL)

 Function Call Flow
call fread application

call ReadFile Msvcrt.dll

call NtReadFile
return to caller
Kernel32.DLL

sysenter / syscall
return to caller
NtDll.DLL
User mode

Kernel mode
call NtReadFile NtOskrnl.EXE

NtReadFile:
call driver NtOskrnl.EXE
return to caller

initiate I/O
driver.sys
return to caller
 Brief Overview of WinDbg

 WinDbg is part of the Debugging Tools for Windows

 Other debuggers in the tools: NTSD, CDB, KD
 All debuggers are based on the same engine: DbgEng.Dll
 NTSD & CDB are user mode debuggers
 Practically identical – NTSD spawns a new console window if launched from
a console window
 KD is a kernel mode debugger
 WinDbg can serve as a user mode or kernel mode debugger
 WinDbg is the only one with a graphical user interface
 Most important window is the Command window
 Can do anything
 Some shortcuts available through the menu
Demo

Function call flow

 Summary

 Although there are many Windows editions, the kernel is basically the
same
 User mode processes use subsystem DLLs to access OS functionality
 A system service call entails transitioning from user mode to kernel
mode (and back)
 Windows Internals
Module 4: System Architecture (Part 2)
Pavel Yosifovich
CTO, CodeValue
[email protected]
http://blogs.Microsoft.co.il/blogs/pavely
 Contents

 Core system files

 Multiprocessing
 Subsystems and NTDLL
 System processes
 Wow64
 Summary
 Core system files

 Ntoskrnl.exe
 Executive and kernel on 64 bit systems
 NtKrnlPa.exe
 Executive and kernel on 32 bit systems
 Hal.dll
 Hardware Abstraction Layer
 Win32k.sys
 Kernel component of the Windows subsystem
 Handles windowing and GDI
 NtDll.dll
 System support routines and Native API dispatcher to executive services
 Kernel32.dll, user32.dll, gdi32.dll, advapi32.dll
 Core Windows subsystem DLLs
 CSRSS.exe (“Client Server Runtime SubSystem”)
 The Windows subsystem process
Demo

Core system files

 Symmetric multiprocessing

 SMP
 All CPUs are the same and share main memory and have equal access to
peripheral devices (no master/slave)
 Basic architecture supports up to 32/64 CPUs
 Windows 7 64 bit & 2008 R2 support up to 256 cores
 Uses a new concept of a “processor group”
 Actual number of CPUs determined by licensing and product type
 Multiple cores do not count towards this limit
Demo

SMP
 Subsystems

 A subsystem is a special view of the OS

 Exposes services via subsystem DLLs
 Original NT shipped with Win32, OS/2 and POSIX 1003.1 (POSIX-1)
 Windows XP dropped support for OS/2
 An enhanced POSIX version is available with the “Services for UNIX” product
 The Windows subsystem must always be running
 Owner of keyboard, mouse and display
 Some API functions use the Advanced Local Procedure Call (ALPC) to
notify CSRSS of relevant events
 Other subsystems configured to load on demand
 Subsystem information stored in registry:
HKLM\System\CCS\Control\Session Manager\Subsystems
Subsystems in the registry
 Subsystem DLLs

 Every image belongs to exactly one subsystem

 Value stored in image PE header
 Can view with Dependency Walker (depends.exe)
 Allows the Windows Loader to make correct decisions
 An image of a certain subsystem calls API functions
exposed through the subsystem DLLs
 E.g. kernel32.dll, user32.dll, etc. for the Windows
subsystem
 Some images belong to no subsystem
 “Native” images
 Which API functions do they call?
 The Native API

 Implemented by NTDLL.DLL
 Used by subsystem DLLs and “native” images
 Undocumented interface
 Lowest layer of user mode code
 Contains
 Various support functions
 Dispatcher to kernel services
 Most of them accessible using Windows API “wrappers”
Demo

Subsystem DLLs and NTDLL

 System Processes

 Idle process
 System process
 Session Manager (Smss.Exe)
 Windows subsystem (Csrss.Exe)
 Logon process (Winlogon.Exe)
 Service control manager (SCM) (Services.Exe)
 Local security authentication server (Lsass.Exe)
 Local session manager (Lsm.exe)
 Idle Process

 Always has a PID of 0

 Not a real process (does not run any executable image)
 One thread per CPU (core)
 Accounts for idle time
 System Process

 Has a fixed PID (4)

 Represents the kernel address space and resources
 Hosts system threads
 Threads created by the kernel and device drivers
 Execute code in system space only
 Created using the PsCreateSystemThread kernel API (documented in the
WDK)
 Allocate memory from the system pools
Demo

Idle and System processes

 Session Manager

 Running the image \windows\system32\smss.exe

 The first user mode process created by the system
 Main tasks
 Creating system environment variables
 Launches the subsystem processes (normally just csrss.exe)
 Launches itself in other sessions
 That instance loads WINLOGON and CSRSS in that session
 Then terminates
 Finally
 Waits forever for csrss.exe instances to terminate
 If any of them dies, crashes the system
 Waits for subsystem creation requests
 Waits for terminal services session creation requests
 Winlogon

 Running the image \windows\system32\winlogon.exe

 Handles interactive logons and logoffs
 If terminated, logs off the user session
 Notified of a user request by the Secure Attention Sequence (SAS),
typically Ctrl+Alt+Del
 Authenticates the user by presenting a username / password dialog
(through LogonUI.exe)
 Can be replaced
 Sends captured username and password to LSASS
 If successfully authenticated, initiates the user’s session
 LSASS

 Running the image \windows\system32\Lsass.exe

 Calls the appropriate authentication package
 Upon successful authentication, creates a token representing the
user’s security profile
 Returns information to Winlogon
 Service Control Manager (SCM)

 Running the image \windows\system32\services.exe

 Responsible for starting, stopping and interacting with service
processes
 Services
 Similar to UNIX “daemon processes”
 Normal Windows executables, that interact with the SCM
 Can be started automatically when the system starts up without an
interactive logon
 Can run under “special” accounts
 LocalSystem, NetworkService, LocalService
 Local Session Manager

 Introduced in Windows Vita

 Running the image \windows\system32\lsm.exe
 In windows 8, turned into a service
 Implemented in \windows\system32\lsm.dll
 Hosted in a standard svchost.exe
 Manages terminal sessions on the local machine
 Communicates requests to SMSS
Demo

Services
 Wow64

 Allows execution of Win32 binaries on 64-bit Windows

 Wow64 intercepts system calls from the 32-bit application
 Converts 32-bit data structure into 64-bit aligned structures
 Issues the native 64-bit system call
 Returns any data from the 64-bit system call
 The IsWow64Process function can tell whether a process is running
under Wow64
 Address space is 2GB or 4GB (if image is linked with the
LARGEADDRESSAWARE flag)
 Device drivers must be native 64 bit
 File system
 \windows\system32 contains 64 bit images
 \windows\syswow64 contains 32 bit images
 Wow64 Architecture

32 bit EXE, DLLs

32 bit NtDll.Dll

Wow64Cpu.Dll

Wow64.Dll Wow64Win.Dll

64 bit NtDll.Dll

NtOsKrnl.Exe Win32k.Sys
 Wow64 Restrictions

 A 64 bit process cannot load a 32 bit DLL and vice versa

 Except resource-only DLLs, which can be loaded cross-architecture
 Some APIs are not supported by Wow64 processes
 E.g. ReadFileScatter, WriteFileGather, AWE functions
 File System Redirection

 System directories names have not changed in 64 bit Windows (e.g.

\Windows\System32 contains native 64 bit images)
 32 bit applications must use their own directories
 \Windows\System32 maps to \Windows\Syswow64
 32 bit apps installed in \Program Files (x86)
 64 bit apps installed in \Program Files
 Some directories are not redirected
 Registry Redirection

 Components trying to register as 32 bit and 64 bit will clash

 32 bit components are redirected to the Wow64 registry node
(Wow6432Node)
 HKEY_LOCAL_MACHINE\Software
 HKEY_CLASSES_ROOT
 HKEY_CURRENT_USER\Software\Classes
 New flags for Registry APIs allow access to the 64 bit or 32 bit nodes
 KEY_WOW64_64KEY – open a 64 bit key
 KEY_WOW64_32KEY – open a 32 bit key
Demo

Wow64
 Summary

 A Process executes under a specific subsystem

 The primary subsystem is the Windows subsystem
 NTDLL is the gateway to kernel mode
 Wow64 allows running 32 bit processes on 64 bit systems
transparently
 Windows Internals
Module 5: Processes & Threads
Pavel Yosifovich
CTO, CodeValue
[email protected]
http://blogs.Microsoft.co.il/blogs/pavely
 Contents

 Processes
 Threads
 Thread scheduling
 Thread synchronization
 Thread pools
 Jobs
 Summary
 Process

 Management and containment object

 Owns
 Private virtual address space (2GB/3GB on 32 bit, 8TB on 64 bit)
 Working set (physical memory owned by process)
 Private handle table to kernel objects
 Access token
 Has a priority class (from Win32)
 Affects all threads running in that process
 Basic creation functions: CreateProcess, CreateProcessAsUser
 Terminated when any of the following occurs
 All threads in the process terminate
 One of the threads calls ExitProcess (Win32)
 Killed with TerminateProcess (Win32)
 Process creation

 Flow of process creation

 Open image file
 Create kernel Executive Process object
 Create initial thread
 Create kernel Executive Thread object
 Notify CSRSS of new process and thread
 Complete process and thread initialization
 Load required DLLs and Initialize
 DllMain function called with DLL_PROCESS_ATTACH reason
 Start execution of main entry point (main / WinMain)
Demo

Creating a Process
Demo

Process internals
 Threads

 Instance of a function executing code

 Owns
 Context (registers, etc.), 2 stacks (user mode and kernel mode)
 Optionally, message queue and Windows
 Optional security token
 Scheduling state
 Priority (0-31)
 State (Ready, Wait, Running)
 Current access mode (user or kernel)
 Basic creation function: CreateThread (Win32)
 Destroyed when
 Thread function returns (Win32)
 The thread calls ExitThread (Win32)
 Terminated with TerminateThread (Win32)
Demo

Creating threads
 Windows Internals
Module 6: Processes & Threads (Part 2)
Pavel Yosifovich
CTO, CodeValue
[email protected]
http://blogs.Microsoft.co.il/blogs/pavely
 Thread Stacks

 Every user mode thread has two stacks

 In kernel space (12K (x86), 24K (x64))
 Resides in physical memory (most of the time)
 In user space (may be large)
 By default 1MB is reserved, 64KB committed
 A guard page is placed just below the last committed page, so that the stack can
grow
 Can change the initial size
 Using linker settings as new defaults
 On a thread by thread basis in the call to CreateThread / CreateRemoteThread(Ex)
 Can specify a new committed or reserved size, but not both
 Committed is assumed, unless the flag STACK_SIZE_PARAM_IS_A_RESERVATION is
used
Demo

Thread stacks
 Thread Priorities

 Thread priorities are between 1 and 31 (31 being the highest)

 Priority 0 is reserved for the zero page thread
 The Windows API mandates thread priority be based on a process
priority class (base priority)
 A thread’s priority can be changed around the base priority
 APIs (Win32)
 SetPriorityClass – changing process base priority
 SetThreadPriority – change the thread priority offset from the parent’s
base priority
 API (kernel)
 KeSetPriorityThread – change thread priority to some absolute value
 Thread Priorities (Win32 View)
Normal Priorities Realtime Priorities

Realtime Priority Class

High Priority Class

Above Normal Priority Class

Normal Priority Class

Below Normal Priority Class

Idle Priority Class

1 4 6 8 10 13 15 16 24 31
Priority
Demo

Thread Priorities
 CPU
Ready
Running
priority
5
31

16

8 6 4

4 7

Waiting

888 2 1 3
 Thread Scheduling (single processor)

 Priority based, preemptive, time-sliced

 Highest priority thread runs first
 If time slice (quantum) elapses, and there is another thread with the same
priority in the Ready state – it runs
 Otherwise, the same thread runs again
 If thread A runs, and thread B (with a higher priority) receives something it
waited upon (message, kernel object signaling, etc.), thread A is preempted
and thread B becomes the Running thread
 Voluntary switch
 A thread entering a wait state is dropped from the scheduler’s Ready list
 Typical time slice is 30 msec on client, 180 msec on server
 On an MP system with n logical processors, n concurrent threads
may be running
 Thread States

Init (0)
Preemption,
Preempt quantum end

Ready, (1)
Deferred Standby (3) Running (2)
Ready (7)

Voluntary
switch
Transition (6)

Waiting (5)
Kernel
Terminate (4)
stack outswap
 The Scheduler

 Scheduling routines are called when scheduling events occur

 Interval Timer interrupts checks for quantum end and timed wait
completion
 I/O Completion calls
 Changes in thread priority
 Changing state of waitable object other threads are waiting on
 Entering a wait on one or more objects
 Entering Sleep
Demo

Thread Scheduling
 The Quantum

 Scheduler clock tick is typically

 10 msec (uniprocessor)
 15 msec (multiprocessor)
 Can determine with clockres.exe utility from SysInternals
 Default client quantum is 2 clock ticks
 Default server quantum is 12 clock ticks
 Quantum can be modified by using the registry or a Job
 Quantum boosting
 On a system configured for short, variable quantum
 The foreground process gets triple quantum
 For any process with a priority class above Idle
 Quantum Control

 Registry key: HKLM\SYSTEM\CCS\Control\PriorityControl

 Value: Win32PrioritySeparation
4 2 0
Short vs. Long Variable vs. Fixed Foreground Priority Boost

 Short vs. Long

 1=long, 2=short
 0, 3=deafult (long for Server, short for Client)
 Variable vs. Fixed
 1=boost priority of foreground process, 2=don’t boost
 0, 3=default (boost for Client, don’t boost for Server)
 Foreground quantum boost
 Index into a table
Short Long
Variable 6 12 18 12 24 36
Fixed 18 18 18 36 36 36
Demo

Thread Quantum
 Windows Internals
Module 7: Processes & Threads (Part 3)
Pavel Yosifovich
CTO, CodeValue
[email protected]
http://blogs.Microsoft.co.il/blogs/pavely
 Priority Boosts

 Windows boosts the priority of threads in a number of scenarios

 Completion of I/O operations
 After waiting for events or semaphores
 During waiting for an executive resource
 After threads in the foreground process complete a wait operation
 When GUI threads wake up because of windowing activity
 When a thread is starved
 Thread priorities in the realtime range don’t receive any boost
 Completion of I/O Request or Wait

 Occurs when an I/O or wait completes

 Can be specified by a driver or the Executive
 KeSetEvent (Event, Increment)
 IoCompleteRequest (Irp, PriorityBoost)
 After a boost, thread runs for one quantum at that priority
 Then drops one level, runs another quantum
 Then drops another level, etc., until back to base priority
 Recommended boost values defined in <ntddk.h>

#define IO_SERIAL_INCREMENT 2
#define EVENT_INCREMENT 1
#define IO_KEYBOARD_INCREMENT 6
 Thread Priority Boost and Decay

Priority
quantum

Priority Preempted
boost upon (before
wait quatum
completion end)
Base
Priority Run Wait Run Wait Run

Time
 Foreground Process Wait Boost

 Foreground process
 The process which contains the thread who is the owner (and creator) of the
foreground window
 After a thread running in the foreground process completes a wait
on a kernel object
 Receives a boost in the amount of the value set in the registry for
foreground priority boost
 +2 by default
 GUI Thread Wakeup

 GUI threads receive a priority boost of 2 when they wake up due to a

Window message arriving
 Provided by Win32k.sys
 Improves their chance of running sooner, giving a better
responsiveness to the user
 Priority Inversion / Starvation

 Priority Inversion
 High-priority thread waits on something locked by a lower priority thread
which can’t run because of a middle priority thread running
 Boosts thread to avoid priority inversion
 Threads staying in ready state a long time (four seconds) get a big boost to
priority 15
 Get to run for 3 quantums at this special boost Wait
 Then priority drops to base 12
 Technically, starvation avoidance
 Implemented by the balance set manager 7 Run
 Scans at most 16 threads per pass
 Boosts at most 10 threads per pass
4 Ready
Demo

Priority boosts
 Multiprocessing - Soft affinity

 Ideal Processor
 Every thread has an ideal processor
 Default value set in round-robin within each process
 A random starting value
 Can Override with SetThreadIdealProcessor
 On hyper-threaded systems, the next ideal processor selected is from the
next physical core (not logical)
 Multiprocessing - Hard Affinity

 Threads can run on any CPU unless hard affinity is set for that thread
 SetThreadAffinityMask
 The mask is a bit mask of allowed CPUs to run that thread
 Default is process affinity mask, which defaults to all processors
 Calling SetProcessAffinityMask changes priority mask for all threads
running under that process
 And future created threads in that process
 Using hard affinity may result in threads getting less CPU time
 Multiprocessor Scheduling

 Single CPU scheduling is relatively simple

 Use the highest priority thread
 Multi CPU systems complicate things
 Windows attempt to balance priority needs with thread’s preferred and
previous CPUs
 The only guarantee is that one of the highest priority threads is running on
some CPU
 NUMA (Non uniform memory architecture) complicate things
further
 Scheduling on Multi-CPU System (Simplified)
A thread is
ready

Is ideal CPU
Y running N Is there Y Y
Is ideal
Use it lower an idle Use it
priority CPU idle?
CPU?
thread?

N
N
Is Y
previous Use it
Add it to the ideal CPU idle?
CPU’s ready
queue N

N Is current Y
Use it
CPU idle?
Find and use first
numbered idle CPU
 Thread Synchronization

 Threads sometimes need to coordinate work

 Canonical example
 Accessing a linked list concurrently from multiple threads
 Synchronization is based upon waiting for some condition to occur
 The kernel provides a set of synchronization (dispatcher) primitives
on which threads can wait efficiently
 Kernel Dispatcher Objects

 Maintain a state (signaled or non-signaled)

 The meaning of “signaled” depends on the object type
 Can be waited to change to the signaled state
 Windows API: WaitForSingleObject, WaitForMultipleObjects and their
variants
 Kernel mode: KeWaitForSingleObject, KeWaitForMultipleObjects
 Dispatcher object types
 Process, thread, event, mutex, semaphore, timer, file, I/O completion port
 Higher level wrappers exist
 MFC: CSyncObject (abstract base of CMutex, CSemaphore and others)
 .NET: WaitHandle (abstract base of Mutex, Semaphore and others)
 “Signaled” Meaning

 Process
 The process has terminated
 Thread
 The thread has terminated
 Mutex
 The mutex is free
 Event
 The event flag is raised
 Semaphore
 The semaphore count is greater than zero
 File, I/O completion port
 I/O operation completed
 Timer
 Interval time expires
 Mutex

 Mutual exclusion
 Called Mutant in kernel terminology
 Allows a single thread to enter a critical region
 The thread that enters the critical region (its wait has succeeded) is
the owner of the mutex
 Releasing the mutex allows one (single) thread to acquire it and
enter the critical section
 Recursive acquisition is ok (increments a counter)
 If the owning thread does not release the mutex before it terminates, the
kernel releases it and the next wait succeeds with a special code (abandoned
mutex)
 Semaphore

 Maintains a counter (set at creation time)

 Allows x callers to “go through” a gate
 When a thread succeeds a wait, the semaphore counter decreases
 When the counter reaches zero, subsequent waits do not succeed (state is
non-signaled)
 Releasing the semaphore increments its counter, releasing a thread that is
waiting
 Is a Semaphore with a maximum count of one equivalent to a
Mutex?
 Does not maintain any ownership
 Event

 Maintains a Boolean flag

 Event types
 Manual reset (Notification in kernel terminology)
 Auto reset (Synchronization)
 When set (signaled) threads waiting for it succeed the wait
 Manual reset event releases any number of threads
 Auto reset event releases just one thread
 And the event goes automatically to the non-signaled state
 Useful when no other object fits the bill
 Provides flow synchronization as opposed to data synchronization
 Critical Section

 User mode replacement for a mutex

 Can be used to synchronize threads within a single process
 Operates on a structure of type CRITICAL_SECTION
 Cheaper than a mutex when no contention exists
 No transition to kernel mode in this case
 Uses EnterCriticalSection and LeaveCriticalSection API functions
 No way to specify a timeout other than infinite and zero
 Zero is accomplished with TryEnterCriticalSection
 .NET
 A similar effect is achieved with the lock C# keyword
 Calls the framework’s Monitor.Enter/Exit in a try/finally block
Demo

Thread Synchronization
 More threading

 Thread pools
 Simplifies thread management
 Potentially boosts performance as threads don’t need to be
created/destroyed explicitly
 C++11 and .NET 4+ provide helpers for fork/join scenarios
 parallel_for (C++), Parallel.For (.NET)
 Simplify operations where order is unimportant
 Other higher level threading helpers exist in C++ 11 and .NET 4+
 Manual thread management considered “low level”
 Understanding threads can help make the right choices and solve problems
Demo

Automatic parallelization
 Jobs

 Kernel object that allows managing one (or more) processes as a

unit
 System enforces Job quotas and security
 Total and per process CPU time, working sets, CPU affinity and priority class,
quantum length (for long, fixed quantums only)
 Security limits
 UI limits
 API
 CreateJobObject / OpenJobObject
 AssignProcessToJobObject
 TerminateJobObject
 SetInformationJobObject
Demo

Jobs
 Summary

 Process is a management object

 Threads are the real workers
 Windows schedules threads to run on processors
 Understanding the way threads and processes work helps in design,
debugging and troubleshooting