Systems Programming
Meeting 1:
Systems Technology: Program,
Process & Thread Overview
GWU CS 259 Brad Taylor Spring 2004
1
Objectives
•Value / Motivation (Experiment to Start)
•Course Mechanics
•Course Topic Overview
•Defining Systems Programming
GWU CS 259 Brad Taylor Spring 2004
2
Thought Experiment
•Everyone chose role:
hardware (I/O, CPU, memory, system
bus & clock), OS (processes, signals),
application (pseudo code), operator
•Need: A card from deck
•Walk thru (clock cadence):
- Operator ‘runs’ processes (stored in
memory), supplying parameter(s)
- Operands read from file (input),
processes retrieved from memory files,
ALU perform calculations in registers,
writes results to separate file (output) …
•What if some hurdle was added (i.e.,
process file relocation)?
•Lessons Learned?
•This is Systems Programming!
GWU CS 259 Brad Taylor Spring 2004
3
Systems Programming
Motivation
•Familiar with the ‘dominant OS’
incompatibilities?
•Exploding growth of web uses/
users (linear?) exacerbates issue
•Systems & Applications:
designed to perform specific tasks
and functions. Do they?
•Goes wrong examples: IEEE,
NASA/ESA, Power Grids & Plant,
costs to $BBs
•Fix it sooner or later?
(Easier, faster vs. ‘hero’)
{Web version: sorry, no movie clip}
GWU CS 259 Brad Taylor Spring 2004
4
Systems Programming
Motivation (more …)
•At Operating Systems & Application Programming
intersection: Learn to develop precise code where
required or systems library use where available
•Fundamentals (UNIX/LINUX programs, processes, files,
directories, I/O, programming tools, token ring)
•Asynchronous Events (signals, timers)
•Concurrency (threads, synchronization, critical sections,
semaphores, inter-process communication, SMP/Cray)
•Communication (connection-oriented, wireless,
MANET/ProxiNet)
•Project (develop actual release modules for open source
reusable library for scripting programs—expert in our midst!)
GWU CS 259 Brad Taylor Spring 2004
5
Course Mechanics
Course Web Page:
www.seas.gwu.edu/~csci259/
(materials, links, assignments, exams)
Email to:
btaylor@gwu.edu (questions, anytime)
CSCI259@gwu.edu (assignments, exams)
Office Hours: Monday 5 - 6pm, Phillips Hall
720 (or by appt.)
Prereqs: CSci 210; ‘C’ & UNIX experience;
SEAS (or other) UNIX account access
A little background?
GWU CS 259 Brad Taylor Spring 2004
6
Course Mechanics (more)
Text: UNIX Systems Programming: Communication,
Concurrency, and Threads, by Kay A. & Steven
Robbins (skim before, study after class),
supplementary materials provided and can be
found (web links, bookstore)
Class time is discussion; not simply lecture
Homework from web page, due by email:
collaboration allowed in study; final product,
your own; course project ~ 3 person groups.
Programming assignments require archive file with
‘readme’ (contents, instructions), source code,
executable (SEAS UNIX), test cases & results
Coding Guidelines (3 D’s: Document, document…)
GWU CS 259 Brad Taylor Spring 2004
7
Relationship to other coursework
• Programming (learn to use those involving
aspects of hardware and system calls)
• Operating Systems (addresses how
distributed systems programs use OS services)
• Networks (natural progression from Internet
Protocols’ specifics to general case)
• Architecture (how components interact)
• Formal Methods (critical systems calls either
robust or complicit in system crashes)
GWU CS 259 Brad Taylor Spring 2004
8
But What Would I Use It For?
•Single Computer Applications
•Networked, Complex Systems
•Team & Individual Projects
•Safety Critical Applications
•Timing Critical Assignments
GWU CS 259 Brad Taylor Spring 2004
9
What will I get out of this?
• Understand & apply course concepts & logic, their strengths
& weaknesses
• Choose appropriate methods for particular system classes
• Describe relations between various levels of abstraction
• OS ‘Primeval mud’ of computer system: demystify
• OS instance of Complex System: similar to biological (ants,
DNA, neurons), weather, social (cities, bf/gf), internet
examples; all emergent, huge, parallel, not well understood
• Strategy: Use abstraction, modularity & iteration
{fail early, often, grow from working simple “Hello World”
model!}
GWU CS 259 Brad Taylor Spring 2004
10
Operating Systems
•Operating systems: the
applications’ interface to
hardware
•Even if hardware doesn’t
change (though it will), every
patch, version update, etc.
may appear as hardware
change to applications
•Challenges/Benefits of
multiple applications/users
•Adds security (or insecurity)
GWU CS 259 Brad Taylor Spring 2004
11
Acquiring Systems
Programming Tools
Links will be available to
academically available
materials
GWU CS 259 Brad Taylor Spring 2004
12
Systems Programming
•Key Characteristics? (Brainstorm)
•Reliability, Robustness, Maintainability
•Reliability: Specification provided & validated,
within resources (budget) {Note: the latter is
promoted by early definition of the former –
using methods we will cover – but multiple
iterations expected}
•Robustness: Graceful degradation response to
unanticipated exceptions {Software failure rate
inversely (vs. hardware, directly) related to time}
•Maintainability: Handle circumstances
changing with time (operators, hardware,
operating systems, archive media; ex: storage
access vs. processor speed gap widens)
GWU CS 259 Brad Taylor Spring 2004
13
Embedded Processor OS
•Critical / Safety
Applications
•Cars: networks
< $10 per node
•Chemical plants
•Avionics
•Remote spacecraft
Robustness and Security issues not confined to
this context, but clear here
Consider remote ‘OnStar’ login & buffer overflow
GWU CS 259 Brad Taylor Spring 2004
14
Design Process:
Abstractions & Mathematics
• Mathematical models (abstractions) represent
real world systems; OS abstracts hardware &
provides greater platform portability
• Formal methods & reasoning improve system
design & production ability (reveal design flaws,
define requirements precisely, implement
rational production)
• Various logical models have differing strengths
and weaknesses
• Abstraction: focus on important problem aspects
• Mathematics: reason about problem solutions
GWU CS 259 Brad Taylor Spring 2004
15
Where did these systems begin?
• Evolution from: abacus, slide rule, mechanical calculators
& difference engines
• Turing machine realized with room of vacuum tubes;
programming by physical switches, patch wire and lights;
“time sharing” by assigned time (hour) on machine
• Enhanced input methods: (paper) card & tape readers,
magnetic tape and disk storage, now optical and soon
holographic means; interface evolved first along typewriter
path, then GUI
• Output improvements followed similar path
• Meanwhile time sharing progressed from batch processing
to multitasking mainframes with ‘dumb’ terminals; then
stand-alone single-user PCs, now networked thru Internet
• Resource sharing of certain network elements (e.g.,
printers, gateways)
GWU CS 259 Brad Taylor Spring 2004
16
What OS Tools handle Concurrency?
• Interrupts (handling, context switches, device drivers for
particular I/O)
• Signals (synchronous or asynchronous) as software event
notification
• I/O with significantly different handling characteristics
(cache access vs. user keyboard entry)
• Processes (how different from programs?) started using
fork; communication through pipes (common ancestor)
or signals, FIFOs/named pipes, semaphores, shared
memory, or messages
• Threads (how different from processes?) provide a further
level of concurrency & further potential resource conflicts
• Multiple processors (SMP or ASMP) with distributed
[network] or shared [Cray/IBM] memory (consider ant
colonies & brain neurons)
GWU CS 259 Brad Taylor Spring 2004
17
Programs, Processes & Threads
• Compiled program organized into functions, linked with
necessary libraries, with certain defined parameters, stored on
disk
• Process is a program instance copied by OS into particular
memory space, allowing for tracking variable values (process
state), and assigns a unique process ID to distinguish it
• Each flow of control thru the process is a thread; each of which
will have a subset of memory space assigned, unique state &
identification
• Threads each have an execution stack, program counter, set of
registers and variable state; synchronization to share resources
is key
GWU CS 259 Brad Taylor Spring 2004
18
Program Image
•
•
•
•
•
•
•
•
Executable appears in contiguous memory block
Diagram on board …
Environment & command line parameters
Activation records for each function call on stack
Heap memory allocations
Uninitialized static data
Initialized static data
NOTE: static variables may make program unsafe for
threads (Key: Handling re-entrant functions)
GWU CS 259 Brad Taylor Spring 2004
19
System Function Calls, Process
Environment & Termination
• System libraries provide wealth of functions to
interface hardware with application; properly used
and handling all errors, powerful; improperly
handled: system crash (Ex: Koopman & MS VP)
• Environmental variables provide an array of pointers
to strings to pass system- and/or user- specific
information upon starting a new process for
initialization
• Proper termination of a process includes notifying
parent process (or init if a zombie, no parent) and
releasing resources, resetting OS status info
GWU CS 259 Brad Taylor Spring 2004
20
Conclusion
•The cost of poor systems programming is significant
and rising (MS?)
•Systems programming alternatives:
- poor design and significant modification during
testing, validation and operation; or
- good design and minor changes during system
validation
•Course will develop your knowledge of operating
systems fundamentals and concepts of asynchronous
event notification, concurrency & communication;
applicable to most, primarily focus on Unix (POSIX)
•Plenty of interaction in class, demonstration of skills
on assignments, projects & exams
•Questions? Comments?
GWU CS 259 Brad Taylor Spring 2004
21