Download - CSE 451: Operating Systems

Transcript
Page 1: CSE 451: Operating Systems

CSE 451: Operating

SystemsSection 1

Page 2: CSE 451: Operating Systems

2

Why are you here?

9/30/10

Page 3: CSE 451: Operating Systems

3

Why are you here?

Because you want to work for Microsoft and hack on the Windows kernel?

9/30/10

Page 4: CSE 451: Operating Systems

4

Why are you here?

Because you want to work for Microsoft and hack on the Windows kernel?

Because it fulfills a requirement and fits your schedule?

9/30/10

Page 5: CSE 451: Operating Systems

5

Who cares about operating systems?

Operating systems techniques apply to all other areas of computer science Data structures; caching; concurrency;

virtualization…

9/30/10

Page 6: CSE 451: Operating Systems

6

Who cares about operating systems?

Operating systems techniques apply to all other areas of computer science Data structures; caching; concurrency;

virtualization…

Operating systems support all other areas of computer science

9/30/10

Page 7: CSE 451: Operating Systems

7

Who are we?

Peter Hornyack

Abdul Salama

9/30/10

Page 8: CSE 451: Operating Systems

8

Who are we?

Peter Hornyack

Abdul Salama

What do we know?

9/30/10

Page 9: CSE 451: Operating Systems

9

Who are we?

Peter Hornyack

Abdul Salama

What do we know?

Why are we here?

9/30/10

Page 10: CSE 451: Operating Systems

10

What is this section for?

Projects

Questions!

Extensions beyond lecture / textbook material

9/30/10

Page 11: CSE 451: Operating Systems

11

Office Hours

9/30/10

Page 12: CSE 451: Operating Systems

12

Outline

Introduction

C vs. Java

C language “features”

C pitfalls

Project 0

9/30/10

Page 13: CSE 451: Operating Systems

13

Motivation: Why C?

Why not write OS in Java?

9/30/10

Page 14: CSE 451: Operating Systems

14

Motivation: Why C?

Why not write OS in Java? Interpreted Java code runs in VM; what

does VM run on?

9/30/10

Page 15: CSE 451: Operating Systems

15

Motivation: Why C?

Why not write OS in Java? Interpreted Java code runs in VM; what

does VM run on?

Precision: Instructions Timing Memory

9/30/10

Page 16: CSE 451: Operating Systems

16

C vs. Java: CompilationJava

Packages“import

java.xyz”

.class files

jar program .jar files

C Header files

“#include xyz.h”

.o files

linker program Executable files libc

9/30/10

Page 17: CSE 451: Operating Systems

17

C vs. Java: ConstructsJava

Classes Public or private

members

Methods Instantiated with class,

or may be static

References

C Structures

All members “public”

Functions Implicitly “static”

Pointers

9/30/10

Page 18: CSE 451: Operating Systems

18

C Language Features

Pointers

Pass-by-value vs. pass-by-reference

Structures

Typedefs

Explicit memory management

9/30/10

Page 19: CSE 451: Operating Systems

19

Pointers

int a = 5;int b = 6;int *pa = &a; // declares a pointer to a

// with value as the

// address of a*pa = b; // changes value of a to b

// (a == 6)pa = &b; // changes pa to point to

// b’s memory location (on

// stack)

9/30/10

Page 20: CSE 451: Operating Systems

20

Function Pointers

int some_fn(int x, char c) { ... }// declares and defines a

functionint (*pt_fn)(int, char) = NULL;

// declares a pointer to a function

// that takes an int and a char as

// arguments and returns an intpt_fn = &some_fn;

// assigns pointer to some_fn()’s

// location in memoryint a = (*pt_fn)(7, ‘p’);

// sets a to the value returned by

// some_fn(7, ‘p’)

9/30/10

Page 21: CSE 451: Operating Systems

21

Pointer Arithmetic

Array variables are really just pointers:

int foo[2]; // foo is a pointer to the// beginning of

the array*(foo+1) = 5; // the second int in the

// array is set to 5

Don’t use pointer arithmetic unless you have a good reason to

9/30/10

Page 22: CSE 451: Operating Systems

22

Pass-By-Value vs. Pass-By-Reference

int doSomething(int x) {return x+1;

}void doSomethingElse(int *x) {

*x += 1;}void foo() {

int x = 5;int y = doSomething(x); // x==5,

y==6doSomethingElse(&x); // x==6,

y==6}

9/30/10

Page 23: CSE 451: Operating Systems

23

Structures

struct foo_s { // defines a type thatint x; // is referred to as

aint y; // “struct foo_s”.

}; // don’t forget this ;

struct foo_s foo; // declares a struct// on the stack

foo.x = 1; // sets the x field// of the struct

to 1

9/30/10

Page 24: CSE 451: Operating Systems

24

Typedefs

typedef struct foo_s *foo_t;// creates an alias “foo_t” for// pointer to foo_s struct

foo_t new_foo =(foo_t)malloc(sizeof(struct foo_s));

// allocate a foo_s struct on the

// heap; new_foo points to it

new_foo->x = 2;// “->” operator dereferences

the// pointer and accesses the

field x

9/30/10

Page 25: CSE 451: Operating Systems

25

Explicit Memory Management

Allocate memory on the heap:void *malloc(size_t size);

Note: may fail! Use sizeof() operator to get size

Free memory on the heap:void free(void *ptr);

Pointer argument comes from previous malloc() call

9/30/10

Page 26: CSE 451: Operating Systems

26

Common C Pitfalls (1)

What’s wrong and how to fix it?

char* city_name(float lat, float long) {char name[100];...return name;

}

9/30/10

Page 27: CSE 451: Operating Systems

27

Common C Pitfalls (1)

Problem: returning pointer to local (stack) memory

Solution: allocate on heapchar* city_name(float lat, float long) {

char* name =(char*)malloc(100*sizeof(char));

...return name;

}

9/30/10

Page 28: CSE 451: Operating Systems

28

Common C Pitfalls (2)

What’s wrong and how to fix it?

char* buf = (char*)malloc(32);strcpy(buf, argv[1]);

9/30/10

Page 29: CSE 451: Operating Systems

29

Common C Pitfalls (2)

Problem: potential buffer overflow

Solution:int buf_size = 32;char* buf =

(char*)malloc(buf_size*sizeof(char));strncpy(buf, argv[1], buf_size);

Why are buffer overflow bugs important?

9/30/10

Page 30: CSE 451: Operating Systems

30

Common C Pitfalls (3)

What’s wrong and how to fix it?

char* buf = (char*)malloc(32);strncpy(buf, “hello”, 32);printf(“%s\n”, buf);

buf = (char*)malloc(64);strncpy(buf, “bye”, 64);printf(“%s\n”, buf);

free(buf);

9/30/10

Page 31: CSE 451: Operating Systems

31

Common C Pitfalls (3)

Problem: memory leak

Solution:char* buf = (char*)malloc(32);strncpy(buf, “hello”, 32);printf(“%s\n”, buf);free(buf);

buf = (char*)malloc(64);…

9/30/10

Page 32: CSE 451: Operating Systems

32

Common C Pitfalls (4)

What’s wrong (besides ugliness) and how to fix it?

char foo[2];foo[0] = ‘H’;foo[1] = ‘i’;printf(“%s\n”, foo);

9/30/10

Page 33: CSE 451: Operating Systems

33

Common C Pitfalls (4)

Problem: string is not NULL-terminated

Solution:char foo[3];foo[0] = ‘H’;foo[1] = ‘i’;foo[2] = ‘\0’;printf(“%s\n”, &foo);

Easier way: char *foo = “Hi”;

9/30/10

Page 34: CSE 451: Operating Systems

34

Project 0

Description is on course web page now

Due Friday October 8, 11:59pm

Work individually Remaining projects in groups of 3

9/30/10

Page 35: CSE 451: Operating Systems

35

Project 0 Goals

Get (re-)acquainted with C programming

Practice working in C / Linux development environment

Create data structures for use in later projects

9/30/10

Page 36: CSE 451: Operating Systems

36

Project 0 Tips

Try these tools: man pages valgrind gdb

Write your test cases first

9/30/10

Page 37: CSE 451: Operating Systems

37

Project 0 Tips

Part 1: queue To find bugs, try valgrind, then gdb

Part 2: hash table Perform memory management carefully

Check using valgrind

9/30/10

Page 38: CSE 451: Operating Systems

389/30/10