ICCT Wiki

User Tools

Site Tools

Trace: • lecture13
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
at-m42:lecture9 [2009/04/15 17:09] – eechrisat-m42:lecture9 [2011/01/14 12:45] (current) – external edit 127.0.0.1
Line 441: Line 441:
  
 ===== Thread A Runs for a While ===== ===== Thread A Runs for a While =====
- +{{ :at-m42:threada-has-key.png?174|Thread A has the key}} 
-{{ :at-m42:threada.png?171|Thread A}}+{{ :at-m42:locked-object.png?230|object is locked}}
  
   * ''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.1239815359.txt.gz · Last modified: 2011/01/14 12:26 (external edit)