ICCT Wiki

User Tools

Site Tools

Trace:
at-m42:lecture9

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
Last revisionBoth sides next revision
at-m42:lecture9 [2009/04/15 17:15] – eechrisat-m42:lecture9 [2009/04/15 17:46] – eechris
Line 445: Line 445:
  
   * ''Thread A'' attempts to enter ''increment'' method.   * ''Thread A'' attempts to enter ''increment'' method.
-    - ''synchronized'' code, so get the key for this object.+    - ''synchronized'' code, so **get the key for this object**.
     - put the value of ''balance'' into variable ''i''.     - put the value of ''balance'' into variable ''i''.
     - ''balance'' is 0, so ''i'' is now 0.     - ''balance'' is 0, so ''i'' is now 0.
     - Set the ''balance'' to the result of ''i + 1''.     - Set the ''balance'' to the result of ''i + 1''.
     - Now ''balance'' is 1.     - Now ''balance'' is 1.
-    - Return the key +    - **Return the key**. 
-  * Thread A re-enters ''increment'' method. Gets the key. +  * Thread A re-enters ''increment'' method. **Gets the key**. 
     - Put the value of ''balance'' into variable ''i''.     - Put the value of ''balance'' into variable ''i''.
     - ''balance'' is 1, so ''i'' is now 1.     - ''balance'' is 1, so ''i'' is now 1.
Line 458: Line 458:
  
 {{ :at-m42:threadb.png?171|Thread B}} {{ :at-m42:threadb.png?171|Thread B}}
 +{{ :at-m42:locked-object.png?230|Locked object}}
  
   * ''Thread'' B attempts to enter ''increment'' method.   * ''Thread'' B attempts to enter ''increment'' method.
     - The method is ''synchronized'' so we need to get the key.     - The method is ''synchronized'' so we need to get the key.
-    - The key is not available+    - The **key is not available**.
     - ''Thread'' B is "//blocked//" (waiting for key to become available).     - ''Thread'' B is "//blocked//" (waiting for key to become available).
  
Line 467: Line 468:
  
 {{ :at-m42:threada.png?171|Thread A}} {{ :at-m42:threada.png?171|Thread A}}
 +{{ :at-m42:key-available.png?236|Key is available}}
   * Picking up where it left off   * Picking up where it left off
     - Set the ''balance'' to the result of ''i + 1''.     - Set the ''balance'' to the result of ''i + 1''.
     - Now ''balance'' is 2.     - Now ''balance'' is 2.
-    - Return the key+    - **Return the key**
  
 ===== Thread B is selected to run ===== ===== Thread B is selected to run =====
  
 {{ :at-m42:threadb.png?171|Thread B}} {{ :at-m42:threadb.png?171|Thread B}}
 +{{ :at-m42:key-available.png?236|Key is available}}
  
   * ''Thread B'' attempts to enter ''increment'' method.   * ''Thread B'' attempts to enter ''increment'' method.
     - The method is ''synchronized'' so we need to get the key.     - The method is ''synchronized'' so we need to get the key.
-    - The key is available, get the key+    - The **key is available, get the key**
     - Put the value of ''balance'' into variable ''i''.     - Put the value of ''balance'' into variable ''i''.
     - Balance is 2, so ''i'' is now 2.     - Balance is 2, so ''i'' is now 2.
     - Set the ''balance'' to the result of ''i + 1''.     - Set the ''balance'' to the result of ''i + 1''.
     - Now ''balance'' is 3.     - Now ''balance'' is 3.
-    - Return the key+    - **Return the key**
        
  
 ===== Synchronizing on other resources ===== ===== Synchronizing on other resources =====
-Synchronizing on something other than the memory inside an object +  * Synchronizing on something other than the memory inside an object 
-Using non-synchronized objects +  * Using non-''synchronized'' objects 
-Best to wrap everything inside an object and guard it with the object’s own synchronized methods, but you can also: synchronized(syncObject) {   // This code can only be accessed       // by one thread at a time }+  * Best to wrap everything inside an object and guard it with the object's own ''synchronized'' methods, but you can also: <code groovy> 
 +synchronized(syncObject) { 
 +     // This code can only be accessed 
 +    // by one thread at a time 
 + } 
 +</code> 
 + 
 +===== Blocking =====
  
-Blocking 
 Four states of a thread: Four states of a thread:
-1. New: the thread object has been created but it hasn’t been started yet so it cannot run +  - //New//: the thread object has been created but it hasn’t been started yet so it cannot run 
-2. Runnable: thread can be run, when the time-slicing mechanism has CPU cycles available +  - //Runnable//: thread can be run, when the time-slicing mechanism has CPU cycles available 
-3. Dead: normally after thread returns from its run( ) +  - //Dead//: normally after thread returns from its ''run'' method 
-4. Blocked: the thread could be run but there’s something that prevent it. While a thread is in the blocked state the scheduler will simply skip over it and not give it any CPU time +  - //Blocked//: the thread could be run but there’s something that prevent it. While a thread is in the blocked state the scheduler will simply skip over it and not give it any CPU time 
-Becoming Blocked +===== Becoming Blocked =====
-Thread is sleeping: sleep(milliseconds) +
-Thread is suspended: suspend( ). It will not become runnable again until the thread gets the resume( ) message +
-Thread is waiting with wait( ). It will not become runnable again until the thread gets the notify( ) or notifyAll( ) message +
-The thread is waiting for some IO to complete +
-The thread is trying to call a synchronized method on another object and that object’s lock is not available +
-Deadlock +
-A chain of threads waiting on each other, looping back to the beginning +
-No language support to prevent it +
-Tough to debug +
-To create a deadlock only need two threads and two objects +
-Thread deadlock +
-Thread deadlock scenario +
-Thread A enters synchronized method of object foo and gets the key. +
-Thread A goes to sleep +
-Thread deadlock scenario +
-Thread B enters synchronized method of object bar and gets the key. +
-Thread B tries to enter a synchronized method of object foo, but can't get that key (A has it). +
-B "blocks" waiting for foo's key to become available. +
-B keeps the bar key. +
-Thread deadlock scenario +
-Thread A wakes up and tries to enter a synchronized method on object bar., but can't get that key because B has it. +
-A "blocks" waiting for bar's key to become available. +
-Thread A can't run until it get's bar key that B is holding. +
-Thread B can't run until it gets the foo key that A is holding. +
-Deadlock! +
-Summary +
-Single-threaded programming: live by yourself, own everything, no contention for resources +
-Multithreading: suddenly you can have collisions and destroy information, get locked up over the use of resources +
-Multithreading makes Java complicated, but that’s not Java’s fault. Multithreading is hard +
-Lab Exercises +
-1. Inherit a class from Thread and override the run( ) method. Inside run( ), print a message, then call sleep( ). Repeat this 3 times, then return from run( ). Put a start-up message in the constructor and override finalize( ) to print a shut-down message. Make a separate thread class that calls System.gc( ) inside run( ), printing a message as it does so. Make several thread objects of both types and run them to see what happens. +
-2. Create two Thread classes, one with a run( ) that starts up, creates and passes its own handle to an object of the second thread class and then calls wait( ). The other classes’ run( ) should cause a notifyAll( ) in the first thread after some number of seconds have passed, so the first thread can print out a message.+
  
-{{:at-m42:deposit.png|}}+  * Thread is //sleeping//: ''sleep(milliseconds)''. 
 +  * Thread is //suspended//: ''suspend( )''. It will not become runnable again until the thread gets the ''resume( )'' message. 
 +  * Thread is //waiting// with ''wait( )''. It will not become //runnable// again until the thread gets the ''notify( )'' or ''notifyAll( )'' message. 
 +  * The thread is waiting for some I/O to complete. 
 +  * The thread is trying to call a ''synchronized'' method on another object and that object's lock is not available.
  
-===== Heading 1 =====+===== Deadlock =====
  
-<code groovy 1 | Example 1: Everything is an object (at-m42/Examples/lecture02/example1.groovy)> +  * A chain of threads waiting on each other, looping back to the beginning 
-extern> http://www.cpjobling.org.uk/~eechris/at-m42/Examples/lecture02/example1.groovy +  * No language support to prevent it 
-</code> +  * Tough to debug 
-----+  * To create a deadlock only need two threads and two objects 
 + 
 +===== Thread deadlock =====
  
-Notes ...+{{:at-m42:deadlock1.png?768 |Deadlock}}
  
-===== Heading 2 =====+===== Thread deadlock scenario =====
  
-  * [[#Sub head 1]] +{{:at-m42:deadlock2.png?344 | Deadlock 2.}}
-  * [[#Sub head 2]]+
  
 +  * ''Thread'' A enters ''synchronized'' method of object ''foo'' and gets the key.
 +  * ''Thread'' A goes to sleep
  
-===== Summary of this Lecture ==== +===== Thread deadlock scenario =====
-  +
-The ....+
  
 +{{:at-m42:deadlock3.png?455 |}}
  
-  * [[#Heading 1]] +  * ''Thread'' B enters ''synchronized'' method of object ''bar'' and gets the key. 
-  * [[#Heading 2]] +  * ''Thread'' B tries to enter a ''synchronized'' method of object ''foo'', but can't get that key (A has it). 
-  * [[#heading 3]]+  * B "blocks" waiting for ''foo'''s key to become available. 
 +  * B keeps the ''bar'' key.
  
-===== Lab Exercises =====+===== Thread deadlock scenario ===== 
 +{{:at-m42:deadlock4.png?455 |Deadlock1}} 
 +  * ''Thread'' A wakes up and tries to enter a ''synchronized'' method on object ''bar'', but can't get **that** key because B has it. 
 +  * A "blocks" waiting for ''bar'''s key to become available. 
 +  * ''Thread'' A can't run until it gets ''bar'' key that B is holding. 
 +  * Thread B can't run until it gets the ''foo'' key that A is holding. 
 +  * **Deadlock!**
  
-  * [[eg-m42:labs:lab1|Lab 1]] exercises 1-7.+===== Summary ===== 
 +  * Single-threaded programming: live by yourself, own everything, no contention for resources 
 +  * Multi-threading: suddenly you can have collisions and destroy information, get locked up over the use of resources 
 +  * Multi-threading makes programming on the Java Platform complicated. 
 +  * Groovy multithreading easier because of the use of the closure. 
 +  * **Multi-threading is hard**!
  
 ---- ----
at-m42/lecture9.txt · Last modified: 2011/01/14 12:45 by 127.0.0.1