|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 5 of 7
To step through the sequence of events that led to a corrupted RGBColor object, press the applet's Step button. Press Back to back up a step, and Reset to back up to the beginning. As you go, a
line of text at the bottom of the applet will explain what's happening during each step.
For those of you who can't run the applet, here's a table that shows the sequence of events demonstrated by the applet:
| Thread | Statement | r | g | b | Color |
| none | object represents green | 0 | 255 | 0 | |
| blue | blue thread invokes setColor(0, 0, 255) | 0 | 255 | 0 | |
| blue | blue thread acquires lock | 0 | 255 | 0 | |
| blue | checkRGBVals(0, 0, 255); |
0 | 255 | 0 | |
| blue | this.r = 0; |
0 | 255 | 0 | |
| blue | this.g = 0; |
0 | 255 | 0 | |
| blue | blue gets preempted | 0 | 0 | 0 | |
| red | red thread invokes setColor(255, 0, 0) | 0 | 0 | 0 | |
| red | red thread blocks because object locked | 0 | 0 | 0 | |
| blue | later, blue thread continues | 0 | 0 | 0 | |
| blue | this.b = 255 |
0 | 0 | 0 | |
| blue | blue thread returns and releases lock | 0 | 0 | 255 | |
| red | later, red thread acquires lock and continues | 0 | 0 | 255 | |
| red | checkRGBVals(255, 0, 0); |
0 | 0 | 255 | |
| red | this.r = 255; |
0 | 0 | 255 | |
| red | this.g = 0; |
255 | 0 | 255 | |
| red | this.b = 0; |
255 | 0 | 255 | |
| red | red thread returns and releases lock | 255 | 0 | 0 | |
| none | object represents red | 255 | 0 | 0 |
Note that this version of RGBColor still has temporarily invalid states from time to time. To be specific, at times during the sequence shown above this object's
state does represent the invalid states black and magenta. The trick to synchronization is that while an object is having
one of those temporarily invalid moments, no other classes or objects are allowed to use or observe the state of the object
via other threads.
An alternative way to make an object thread-safe is to make the object immutable. An immutable object is one whose state can't be changed once the object is created.
Immutable objects are, by their very nature, thread-safe simply because threads have to be able to write to an object's instance variables to experience a read/write or write/write conflict. Because no methods (only the constructor) of an immutable object actually write to the object's instance variables, the object is by definition thread-safe.
In this approach to making an object thread-safe, you don't mark critical sections as synchronized. Instead, you separate out the critical sections that read instance variables from those that write to instance variables. The critical sections that read are left as-is. The critical sections that write must be changed so that, instead of altering the current object's instance variables, they create a new object that embodies the new state and returns a reference to that object.
JVMSimulator and Method.java and search for sychronized. http://www.artima.com/insidejvm/applets/sourcecode.html