1 / 30

Software Engineering 3156

Software Engineering 3156. 24-Sep-01 #6: Concurrency and Project Phil Gross. Administrivia. Groups are more or less set HW1 is out ACM ACM Programming Research. Concurrency. Humans perform tasks in parallel Computers need to do so, too

kateb
Télécharger la présentation

Software Engineering 3156

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Software Engineering 3156 24-Sep-01 #6: Concurrency and Project Phil Gross

  2. Administrivia • Groups are more or less set • HW1 is out • ACM • ACM Programming • Research 2

  3. 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? 3

  4. 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 4

  5. 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 5

  6. Threads • Essentially, lightweight processes • Ability to run concurrent sets of code in one process • Access to the same variables, methods: information sharing easy 6

  7. 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 7

  8. 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! 8

  9. 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 9

  10. 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) 10

  11. 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…) 11

  12. 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 12

  13. 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 13

  14. 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 14

  15. Project Stuff • Specific enough? • Lots of info in the XML schema • Unfortunately, you can’t read an XML schema • Hopefully fixing some of that today 15

  16. XML Schema • Define some global complex types • Use these as you define top level elements • Two top level elements in current schema • May be split into two separate schema • One: static structure: the Map element • Two: dynamic messages: the GameEvent element 16

  17. XML Elements • Have a name and a type • Can have a simple type • Often prefixed with xs: • xs:string, xs:int, xs:boolean, etc. • Or can be a complex type • Arbitrarily complex hierarchy 17

  18. Element Children • Three types • Sequence: these elements in this order • Choice: any one of these elements • All: all of these elements in any order • Less common (tough to parse, weird restrictions) • Note that an element is never a direct child of another element 18

  19. Map Element • Contains all the information necessary to describe a game map, including graphics for the client and simple scripts for the AI • Basic entities: • Tiles • Objects • Bots • Actors (user players) 19

  20. Map Element Parts • Metadata – basic info on map • {tile | item | bot}set • For tile and item, unique ID plus URL to graphic • For bot, initial state plus scripts • More on scripts later • {tile | item | bot | actor}instances • An instance of a class at a particular location on the board and with its own instance data • Item instances have behaviors 20

  21. Actors • Bots are an extension of this • Have hp, xp, name, speed attribute • And a status word • 32 bit value • Each bit represents some accomplishment in the game • Interactions with objects and bots can set bits • Setting bit 31 ends game • Covers both inventory and plot progression 21

  22. Bots • Have a state, and sometimes a target, plus possibly a master • State: current activity, e.g. attacking, fleeing, wandering, conversing, assisting • State says what to do, but it’s up to the AI to actually do it • Target: for certain states, e.g. attacking • Master: If assisting, this is the character to assist 22

  23. Bot Scripts • For a given state, describe what to do if someone is seen, conversed with, or interacted with • Filter: check any of my and their instance variables • Result: if filter passed, these effects happen • Seeing only allows effect on self (other may be far away) 23

  24. The GameEvent Element • A message between components • AIs and clients request moves • Server evaluates them and sends deltas out to all connected clients/AIs 24

  25. Move And Chat • Movement requests • Checked for validity and timing, and either granted or rejected • Start/EndChat • Enter conversation mode • Send/ReceivedText • Exchange chat messages 25

  26. Attacks And Change • Attacked • Gives result of an assault • ReplaceObject • Bot with a corpse, closed chest with open chest, etc. • ChangeStats • Flip a status bit, give health, hp, xp, gold, etc. • StatusMessage • Get a message from the server 26

  27. Game Entry/Exit • Enter/Quit game • Client requests • KickGame • Server boots you • ExplicitSave • Client requests that current actor state be sent to repository 27

  28. Editor • Get data from Editor mode of client to server • SendObject, LoadMap • Plus confirmations • More work to be done here… 28

  29. Data Transfer • GetMapData • Send absolute info • MapData • The absolute info • MapDelta • Changes since last delta • Deltas have a sequence number for detection of dropped events 29

  30. Exceptions • ExMoveForbidden, ExNoConversation, ExKicked, ExNoPermession, ExUnknown 30

More Related