COMS W3156:Software Engineering, Fall 2001

Lecture #7: Objects II, Concurrency

Janak J Parekh

janak@cs.columbia.edu

Administrativia

• Requirements updated

• Homework 1 out

• We’re still working on v0.6 of the requirements

• Noticing webboard posts

• ACM programming contest this weekend

Next class

• Continue object-oriented conceptual model

• Read Schach ch8: Reusability, Portability, and Interoperability

• Hopefully, we’ll have Rational Rose set up by then

Today’s class

• Finish OOA/UML

• Talk concurrency

• Continue requirements discussion– Explain the very long XML schema

State diagrams (I)

• Generalization of FSM’s– Finite state machines represent a class of

computation models• Idea is that there are formalized states and

transitions between them; start with an initial state and have accepting states

• Regular expressions common application

State diagrams (II)

• Here, states are much more ambiguous, as are transitions– States are often “waiting” points or points of

“long activity”– Edges are “events” or “fulfilled conditions”– Lends itself towards the event programming

paradigm: “sit still until something happens”

Happenings at IdiotBank™

W ait for custom er

W ait for custom er request

Deposit m oney W ithdraw m oney Call the cops

Custom er goes away in handcuffs

G o hom e

/open tellerw indow

Custom er walks in

[Custom er wants to deposit]

[Custom er wantsto w ithdraw]

[Custom er pullsout a gun]

[There is no custom er]

Cops arrive

[It’s after 5pm ]

/thank custom er

/thank custom er

/steady nerves

Arrivehom e

Concurrency

• Humans perform tasks in parallel

• Computers need to do so, too– In reality, not with 1-CPU computers:

“multitasking” simulates

• How do we do it?

• How do we deal with the problems?

First cut

• One of the modern operating system’s tasks is to support job or process control– Allow multiple programs (“processes”) to run

at the same time– ps command on UNIX; CTRL-SHIFT-ESC on

WinNT/2k/XP– Protect one process from another– Not always true: RTOS – to be discussed later

Process control

• First-level solution: run multiple processes– “&” in UNIX– “start” in Win32 OS’s– fork( )– Works surprisingly well – many tasks are

discrete and can be run separately

• Problem– How to share information between processes?– Often overkill

Threads

• Essentially, lightweight processes

• Ability to run concurrent sets of code in one process

• Access to the same variables, methods: information sharing easy

Threads in Java

• Class must extend Thread or implement Runnable– Implement run( ) method– Start by using .start( ), not .run( )– Example– Suhit covering multithreaded server in

recitation this week: perfect example of why you want this

• Handler class executed in Thread: one controller, amny handlers

Life is easy…?

• But wait:– Say both threads modify the same variable– Who wins?

• We do not know

• This is very, very bad – if we want randomness, we use java.util.Random!

Why is it not predictable?

• You’re not the only thing in the system– System calls are affected– One system call may take longer than another,

identical system call

• There exist RTOS’s which are predictable in such situations

Why this is bad

• Banking at IdiotBank™– You’re depositing money– The bank is depositing interest

• Bank software reads your balance to calculate interest

• You deposit• Bank software adds 3% interest, saves your balance

back

– You’ve just lost $20,000! (Well, ~ $19,997)– (They’re not the idiots, you are)

Solution

• Obviously, only one task should be able to access the balance at a time

• Set a lock on bank account– Can only write if you have the lock– synchronized(account) method in Java (example)– When bank starts interest checker, it acquires the lock– Your deposit waits (“blocks”), since it doesn’t have the lock

and can’t acquire it– Bank interest done, release lock– You acquire lock, deposit, release– Perfect! (Except you wanted to deposit before the interest

calculation…)

Still not foolproof

• IdiotBank™’s programmers use synchronize, but move process to night

• Interest process requires access to interest percent table

• They forgot that loan payment deductions occur at night, and needs to access interest percent table too

IdiotBank™ is doomed

• Interest credit process locks account• Loan program runs, locks interest table• Interest credit process blocks on interest

table• Loan program tries to subtract from your

account, blocks there• Each process is waiting to get the other’s

lock• Deadlock

Solving deadlock

• Many tricks– Finer-granularity locks: lock balance

– No read locks, just write locks: loan program doesn’t lock interest table

– Priorities

– Automatic reboot of computer

• Interesting: no way to guarantee there won’t be deadlock

• We’ll discuss more in Concurrency II

Project

• Much of the nitty-gritty details are in the XML schema

• How to read an XML schema

• http://www.w3.org/XML/Schema, and http://www.w3.org/TR/xmlschema-0/ in particular is a useful reference

XML Schema (I)

• Goal: declare a few complex types at the top-level, and drill down levels until you reach primitve types

• Create elements that are instances of the complex types at the top level

• In the current schema, there’s two top-level elements; might get split across two schemas– Map element: static structure– GameEvent element: dynamic structure

XML Schema (II)

• XML elements have a name and a type associated with them– Can be simple type, like xs:int, xs:boolean, etc.– “xs” prefix is a “namespace prefix”, like a

package– Can also be a an arbitrarily complex type

XML Schema (III)

• Each element of a complex type can have children– Sequence: have these subelements in order– Choice: have one of these subelements– All: all of these elements in any order

• Very uncommon (inflexible)

• Elements are never directly under each other

Map element (I)

• Contains information necessary to describe a complete game map or world, including graphics for client and scripts for AI

• Basic subtypes:– Tiles– Objects– Bots– Actors (user players)

Map element (II)

• Metadata: basic info about map• Sets of tiles, items, and bots

– For tile and item: ID plus location of graphic– For bot: initial state plus scripts

• Instances of tiles, items, bots: “placed”– Specifies location– Can be many instances of a tile/item/bot– Item instances have behavior

Actors

• Bots extend this (stay tuned)• Have hitpoints, experience points, name, and

speed attribute• Status word

– 32-bit value– Each bit represents some “accomplishment”– Interactions can cause bits to be set– Setting bit 31 ends the game– Covers both inventory and plot

Bots

• Also have state and target, plus possibly a master

• State: attacking, fleeing, wandering, conversing, assisting, dancing funky chicken– State says what to do, but AI code actually

performs action

• Target: for attacking• Master: follow it and “help” it, for assisting

Bot scripts

• For a given state, describe what to do if someone is seen, conversed with, or interacted with

• “Filter”: mechanism to check any of my and their instance variables

• Result: if filter “passes”, these effects happen• Seeing, as opposed to talking or interacting, only

allows effect on self (other may be far away)

GameEvent element (I)

• Message between components

• AI’s and clients request moves

• Server evaluates moves, sends “deltas” out to all connected clients and AI’s

Move and chat

• Movement requests– Checked for validity and timing, and either

granted or rejected

• Start Chat/End Chat– Enter/leave conversation mode

• Send Text/Received Text– Exchange chat text messages

Attacks and changes

• Attacked– Gives result of an assault– (You never request an attack, just move)

• ReplaceObject– Bot with corpse, chest with opened chest, etc.

• ChangeStats– Flip status bit, give health, gold, etc.

• StatusMessage– Get message from the server

Game entry/exit

• Enter/quit game– Client requests

• KickGame– You’ve been naughty, server kicks you

• ExplicitSave– Client requests actor stats be sent to repository

Editor

• Get data from client editor module

• SendObject, LoadMap– We need to do some more work here

Data transfer

• GetMapData– Client’s request to send absolute info

• MapData– Server’s response with data

• MapDelta– Changes since the last “delta”

• Deltas have a sequence number to detect if help deltas are lost

Exception events

• Server’s method of saying “huh” or “uh-oh”

• ExMoveForbidden

• ExNoConversation

• ExKicked

• ExNoPermission

• ExUnknown

What this means for you

• Hopefully, you’ll have a better idea of what is going back and forth

• We still need to discuss the general architecture more

What this means for us

• We aren’t completely finished, still working on 0.6

• Trying to fix most of the open issues

• You’ll have all the material you need to go full steam ahead next week on the specifications