CSG112 – Computer Systems

Instructor: Peter J Desnoyers

Lecture 3 – Part 1 Date: 09/29/2008

Scribe notes by Rohith Shivakumar

HOMEWORK ASSIGNMENT

• Updated homework assignment is due October 14th

.

• Primary parts of the homework assignment are

1. Reading the binary file into memory.

1st

question : Micro program which when compiled is about 30 bytes or so of machine code. You

need to open that file and read it into memory starting at the proc1 pointer.

Using a function pointer - load something in this memory address, now pretend that it is a pointer to

a type of function and call it.

2. Another major piece of code is in parsing a line (Question 3 – implementing a command line)

More on this is in the 2nd

README file.

Q&A SESSION

Every Tuesday from 10 AM – 11 AM, Room 166 WVH.

QUESTIONS ON ASSIGNMENT

• When you do memory mapping, does it allocate memory?

Yes, init_stuff( ) allocates anonymous memory region with the help of mmap( ). In linux if you malloc( ) a

large memory location it internally uses mmap( ).

• access( ) does error checking before calling the function.

CONTEXT SWITCHING

• To do context switching, you enter using one stack and leave using a different stack.

TODAY’S LECTURE : Concurrent processes

• Processes switching back and forth (even in multi-core CPUs).

• Interrupts can cause execution to switch from one thread of execution to other.

• primary assumption is that these results are serializable.

We will not be able to predict the order in which it takes place.

e.g: - QUEUE

Note: - It has several invariants like most data structures.

• If queue is empty then head = NULL and tail = NULL

• If it has one element then, head and tail points to the same element.

queue(item) val = deque( )

temp = tail; temp = head.next

if temp != NULL head = temp

tail, temp.next = item if temp = NULL

else tail = temp

head, tail = item

• Let us assume that this is the code of a device driver. We have top half of the device driver, the

function that you call basically from the user program. Let this queue up the packets that has to be

sent.

• Let us also assume an interrupt handler which is pulling elements of the queue.

temp = tail[ A ]

-------------------------------------------interrupt

temp = head.next

head = temp[NULL]

if temp == NULL

tail = NULL

interrupt---------------------------------------------------------------

if temp != NULL

tail = B

temp.next = B

race condition

The above example leads to the critical section problem. A critical section is a section of code that we want to

be executed by only one thread of control at once. We want to avoid multiple threads accessing this critical

piece of code simultaneously.

In the above race condition example, if I can make this queue( ) and deque( ) atomic, then there cannot be a

race condition.

How critical section are handled inside an Operating System?

Within an OS we have 2 primitives that we can use

1. Spinlocks

2. Disabling interrupts

Race condition in the queue example wouldn’t have taken place if we had disabled interrupts.

queue(item)

disable_irqs()

temp = tail;

if temp != NULL

tail, temp.next = item

else

head, tail = item

enable_irqs()

But, disabling interrupts can prevent interrupts from coming but it cannot prevent another CPU from

executing the same piece of code. To overcome this we can use spinlocks.

Spinlock is a simple piece of code.

lock

Spinlock : eax = 1 | spinunlock:

Xchg eax, lock | store 0 in lock

if eax == 0 |

We got the lock. Return |

else |

Goto loop |

TRACE

0

What happens if you try to grab spinlock from an interrupt handler?

Interrupt handler does not return and hence it results in a deadlock.

Let us consider that we are writing a thread code and I want to protect memory variable.

do_lock : do_unlock:

grab lock.lock next = pop ( lock.list )

if we didn’t get it if ( next != NULL)

add my thread to lock.wait switch ( next )

context switch else

release lock.lock

The above discussion leads to mutex.

MUTEX

• In OS we used spinlock

• In user programs we use mutex.

In the lecture after the break we will have a look at co-ordinate behavior of threads.

---------------------------------------------END OF PART1: LECTURE 3---------------------------------------------------