• e.g. web browser: some displaying images, some retrieving data from internet
  • or: each tabs in a browser
• to perform tasks efficiently

• e.g. multiple kernel threads created Linux system boot time

• i.e. parallel programming: often in data mining, graphics, AI

• thread creation: light-weight
• as thread shares code, data, and others within the process

• elevators, planes, medical systems, etc.
• single program on concurrent operations

• internally concurrent: to deal w/ concurrent requests by multiple users
• no internal protection needed in kernel

• access to shared data of many current users
• background utility processing: must be done

• concurrent requests from network
• file server / web server / airline reservation systems

• split program & data into multiple threads for parallelism

• independently scheduled & run - instance of execution
• represented by
  • thread ID
  • program counter
  • register set
  • stack
• shares code, data, and OS resources: e.g. open files & signals
• efficiency: depends on no. of cores allocated to the process

• responsiveness
• resource sharing
  • threads: share process resource by default
  • easier than inter-process shared memory / message passing
    • as: threads run within the same address space
• economy
  • thread creation: cheaper than process creation
  • context switch: faster intra-process (thread) than inter-process
• scalability
  • processes: can take advantage of multicore architecture

• and improves concurrency in multicore systems

• dividing tasks: how to divide into separate / concurrent tasks
• balance: each task performing equal amount of work
• data splitting: data used by tasks: divided to run on separate cores
  • 👨‍🎓 dividing seed among farmers to work concurrently
• data dependency: synchronization required if data dependency exist
  • e.g. operation B: requiring completion of operation A
• testing and debuggingL different path of executions: makes debugging difficult

• i.e. doing more than one job over a time
• when multiplexed over time: single process core, scheduler provides concurrency

• but many literatures don't differentiate them

• same operation on each core
• common: in distributed machine learning tasks
• 

• each thread: performing unique operation
• 

• w/ both serial and parallel components

• as $N$ approaches infinity: speedup approaches $1/S$
• serial portion of application: disproportionate effect
  • on performance gained by adding additional cores

• then moving from 1 to 2 cores: give speedup of
• $\frac{1}{0.25+\frac{0.75}{2}}=\frac{1}{0.625}\approx 1.6$

• with its of program counter and private set of register for execution

• register state of a thread: saved, and another thread's is loaded / restored
• address space: remains the same - much smaller context switch
  • and thus much small overhead

• enables overlap of IO with other each activities within a single program
• one thread: running on CPU; another thread doing IO

• program counter, registers, execution flags, stack
• thread: executing on processor when it resides i registers
• PC register: holds address of currently executing instruction
• register: holds root state of the thread (other state in memory)

• execution state: CPU registers, program counter, pointer to stack
• scheduling info: state, priority CPU time
• accounting info
• various pointers: for implementing scheduling queues
• pointer to enclosing process: PCB of belonging process

• one program's address space: different from another's
• i.e. keeping buggy program from thrashing entire system

• contents onf emory (global variables, heap)
• IO state (file descriptors, network connections, etc.)

• kept in TCB: thread control block
• CPU registers (including PC)
• execution stack: parameters, temporary variables, PC saved

• new: thread being created
• ready thread waiting to run
• running: instructions being executed
• waiting: thread waiting for event to occur
• terminated: thread finished execution
  • or: killed by OS / user

• TCBs: organized into queues based on states

• queue for each device / signal / condition: w/ their own scheduling policy

• created & managed by user-level threads library
• users: only visible to programmers

• supported & managed by OS
• users: only visible to OS

• Windows, Linux, Max OS X iOS, Android

• => cannot be scheduled to run on a CPU
• OS: only manages & schedules kernel threads

• primary libraries
  • POSIX Pthreads - POSIX API
  • Windows threads - Win32 API
  • Java threads - Java API

• in a program that OS can take advantage of
  • 👨‍🎓 here! this can be done in parallel manner!
• if no user threads defined: kernel threads can't be scheduled either
• ❓ are kernel threads assigned on runtime?
  • 👨‍🏫 yes; user threads are static though
  • cycles of threads / control / etc.: applies to kernel threads

pthread_t tid;
/* creating thread */
pthread_create(&tid, 0, worker, NULL)

• common ways:
• many-to-one: many user-level thread to one kernel thread
• one-to-one: one user-level thread for a kernel thread
  • most common in modern OS
• many-to-many: many user-level thread to many (usually smaller no. of) kernel thread