Software and s/w Development

Nov 18, 2013 (4 years and 5 months ago)

91 views

Project 2 Overview

CSE451

Andrew Whitaker

Project 2 Overview

Project consists of threaded Java programs

No VMWare / kernel hacking

You can use any
multi
-
processor

Linux
machine

Most (all?) undergrad lab machines are dual core

Run ‘
more /proc/cpuinfo’

to verify

Continue to work in your project teams

General Instructions

Your programs must use proper synchronization

Working functionality is not enough!

Remember the rules we’ve talked about:

All
shared
,
mutable

state must be properly synchronized

Usually with a synchronized block or method

Compound actions must be protected by a single lock

Start early!

Not a huge amount of code, but a lot of new concepts

Thursday’s discussion will be Q & A

Using Other People’s Code

Do it!

But, understand the implications for

May require documentation diving

Part 1: Implementing Semaphores

-
safe
integer

Supports
up

and
down

operations for increment
/ decrement

The semaphore can never go negative

If value == 0, then
down

blocks
before

decrementing

If value == 0, then
up

after

incrementing

Semaphore with value 1 is a lock

Pseudocode

public

class

Semaphore {

private int count;

// block if count == 0

// else, decrement

public

void

down () { }

// increment count

// wake up somebody (if necessary)

public

void

up () { }

}

Semaphores, Continued

Condition variables and semaphores have
equivalent expressive power

One can be implemented with the other

Your solution should not busy wait

Do not use
java.util.concurrent.Semaphore

Or any other off
-
the
-
shelf semaphore implementation

Part 2: Calculating

Step 1
: approximate

using a random
number generator

Step 2
: Convert this program to a multi
-

Step 3
: Benchmark the program with a

Approximation Hint

Consider a circle
inscribed in a square

Imagine throwing a large
number of darts at the
square

Some fraction of darts will
also hit the circle

Use this fraction to calculate

Multi
-

Calculator

Approximating

requires many samples

10s of millions is a reasonable starting point

So, let’s try decomposing the work across

public double calculate(int numSamples, int numThreads) {

return 0.0; // TODO: implement this!

}

Mapping This to Code

join

method is useful for
these sorts of computations

public double calculate(int numSamples, int numThreads) {

for (int i=0;i <= numThreads; i++) {

);

}

for (int i=0;i <= numThreads; i++) {

try {

}

catch (InterruptedException ie) {} //ignored

}

}

Benchmarking

Create a graph with # threads on the x
-
axis and latency on the y
-
axis

Let threads range from 1 to 10

Number of samples should be
fixed

Each thread does a fraction of the total samples

Measure latency with
System.currentTimeMillis()

Part 3: Multi
-

-
multi
-

Why?

Any high
-
throughput web server must handle multiple
requests in parallel

By default, each thread handles one request at a time

Requests are
blocking

Thread is stalled while waiting for network, disk, etc.

Anatomy of a (Single
-
Web Server

1.
Accept a new Socket

2.
request URI (e.g., index.html)

3.
Read desired file into a buffer

4.
Write file over the socket

5.
Close the socket

while (true) {

}

These are

blocking calls

-
per
-
request

1.
Accept a new Socket

2.

while (true) {

}

1.

2.
Read desired file into a buffer

3.
Write file over the socket

4.
Close the socket

5.

-
per
-
Request

requests (and higher throughput)

Blocking operations only stall one thread

Must create PCB, allocate stack

performance

On startup, create a static
pool

processing requests

only once

Overview

1.
Accept a new Socket

2.
Enqueue Socket

while (true) {

}

1.
Dequeue Socket

2.

3.
Read desired file into a buffer

4.
Write file over the socket

5.
Close the socket

while (true) {

}

Web Server, Continued

Step 2: Add a “statistics” page at
http://hostname/STATS

Req/sec over the previous ten seconds

Step 3: Benchmark the web server

Using the provided benchmark tool

Java Timers

See lecture or condition variables

OR,
java.util.Timer

and

Key point: timers run in a separate thread

So, shared state must be properly synchronized

Part 4: GUI Hacking

We provide a simple GUI for calculating
the first N fibonacci numbers

You provide an implementation of the
cancel button

Challenge

Problem: GUI frameworks are single
-

Long
-
lived computations can make the GUI
unresponsive

Solution: Transfer long
-

Requires coordination between the GUI thread

Things You Need to Understand

How task handoff works in the Swing GUI
framework?

In particular,
SwingUtilities.invokeLater

You can call
interrupt

What happens?