+ All Categories
Home > Documents > 4061 Session 29 (5/1). Today Review, Looking Ahead DRM Teaching/TAing evaluations.

4061 Session 29 (5/1). Today Review, Looking Ahead DRM Teaching/TAing evaluations.

Date post: 02-Jan-2016
Category:
Upload: allan-mccarthy
View: 214 times
Download: 0 times
Share this document with a friend
Popular Tags:
33
4061 Session 29 (5/1)
Transcript

4061 Session 29 (5/1)

Today

• Review, Looking Ahead

• DRM

• Teaching/TAing evaluations

Admin

• TCLUG– Networking opportunity– First meeting in a year...good time to start– Tomorrow, this room, 6:30pm - 8:00pm– Learn about linux on a flash drive + food/drink

after the meeting

• Quiz 5• Homework 5• Office Hours Next Week

Trip Report

• Persuasive Computing Conference• iParrot and Pet Plant

– Odd form factors for computing

• Increasing interest in computing among women– Avatars as role models: Gender,

attractiveness, age, ….and species

• VR Lab• The dog clicker

Review: Shell Scripting

• Why? One goal of this class is to become comfortable in *nix.– Hopefully, we are all at becoming comfortable

at the command line, now

• Quick and dirty tool to make life easier

• Used for chaining other applications together– If you need to code an algorithm, use Python

“It is easier to port a shell than a shell script.”

-- Larry Wall

Directions: Shell Scripting

• I have seen very little movement in shell scripting.

• However, CLI continues to diminish in importance.– Does this also mean that shell scripts will

decline in importance?

Review: System Calls

• System calls are the programmer’s interface to operating system features– files– processes– etc.

• OS Protection and Process Isolation– System calls: Kernel mode vs. user mode– Base and limit registers

• What happens when you make a system call?

read(fd, &buffer, nbytes)

Directions: System Calls

• We (programmers) are being taken further from the system calls API by more abstract (usable?) languages– Bytecode-based languages and virtual

machines

• Specialized system calls continue to be added to support emerging technologies and needs– E.g. epoll_create

Review: Unix Security

• The Unix security model is simple but powerful– Many argue that it lacks flexibility

• Files have owners and groups• Permissions: r, w, x

– Owner, owner group, everyone else– x treated a bit differently for files and directories

• files: can you execute?• dirs: can you read the files in the dir?

Directions: Unix Security

• New methods for authentication– fingers, eyes, smart cards

• New (old) methods for declaring permissions may pop up in specialized distros– To make the permissions model more flexible– E.g., access control lists associate a list of rules with

each file (users a and b may read and write, user c may read)

• Personal belief: usability of security gains importance

Review: Processes in Unix

• A process is an abstraction of a running program• The OS is responsible for managing processes:

largely in the PCB– Who owns the process?– When should it next get the CPU?– What is the state of the process?– Which resources does the process have open?

• From a user’s perspective, a process is a logically contiguous piece of memory– program code, data, stack, heap

Review: Processes in Unix

• Fork, exec, wait• Processes form hierarchies• Daemon processes• Processes can be in one of several states:

Directions: Processes

• Scheduling has been receiving attention– Scheduling efficiency under load has been

addressed - the current scheduler is O(1)– But fairness is still an issue (e.g. for

interactive processes)

Review: I/O

• Files serve as abstractions for bytes on disk, terminals, network connections...

• Low-level I/O: open, close, read, write• Opening/Closing a file

– OS tracks open files and offsets by process– File descriptor table, System file table, and i-

nodes

• Reading/writing a file– Buffering: in the kernel or in user-space

Review: Unix File Systems

• Disks are organized into partitions, over which sits a file system– A typical file system in Unix contains space set aside

to track i-nodes, and space for storage• I-nodes contain both information about a file

(use “stat” to see more) and pointers to blocks on disk

• Directories are special files which contain file names

• A given i-node may be referenced by more than one path name– Soft and hard links

Review: IPC

• There are a bunch of ways to share information between running processes– pipes and fifos

• one-way buffers• used by the shell

– signals• asynchronous communication• used by apache admin scripts

– sockets• reliable two-way communication• used by ftp server

Review: Threads

• Lightweight-processes– More efficient to start– Easier to share data

• Threads share the heap, code, and static data with the process, but get their own stack and registers

• posix: create, join• It’s important to write reentrant code, or

else use synchronization...

Review: Synchronization

• Multiple threads that write to shared data structures are trouble

• We need atomic operations to ensure synchronization, otherwise races happen– e.g. TSL can be used

• mutex: a room that can only be entered by one thread at a time

• semaphore: a room that can be entered by a set number of threads at a time

• CV: a condition that must be true before your thread is allowed to proceed

Thank You!

• I learned a lot this semester

• I hope you’ve gotten value out of the course

• Build things, stay curious, read, talk with other geeks

• Stop by to say hi


Recommended