This week's giveaway is in the EJB and other Java EE Technologies forum. We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line! See this thread for details.
In Step 1, Application A obtains an integer value from a data store and places it in memory. That integer variable is set to 10. Application A is then pre-empted and forced to wait on Application B. Step 2 begins and Application B then obtains that same integer value of 10. In Step 3, Application B increments the value to 11. The variable is then stored to memory by Application B in Step 4. In Step 5, Application A increments this value as well. However, because they both obtained a reference to this value at 10, this value will still be 11 after Application A completes its increment routine. The desired result was for the value to be set to 12. Both applications had no idea that another application was accessing this resource, and now the value they were both attempting to increment has an incorrect value. What would happen if this were a reference counter or a ticket agency booking plane tickets?
errr ... Just depends on the real world resource in question.
If it were two threads then you'ed have a lock involved hopefully, to synchronize your reads and writes.
If you really have two applications i.e. separate JVM's / processes (possibly remote to each other)it would depend on what your resource was as a simple example, if you had your value in a remote database the first app would select for update , then the second app select for update ... fail and wait for the first to complete . Depending on what your resources are are available there will be a solution just depends on exactly what your trying to do :-)
If you have no locks involved at all your random answer needs to consider if writing / reading to your resource is atomic if its not then you can get a lot wider range of answers than just the obvious A or B. Again depends on what your resource is 'in real money'.
"Eagles may soar but weasels don't get sucked into jet engines" SCJP 1.6, SCWCD 1.4, SCJD 1.5,SCBCD 5
Joined: Oct 30, 2001
Originally posted by Chris Hurst: errr ... Just depends on the real world resource in question.
I presume that, in the original poster's case, the resource is one that does not have any special support for multiple simultaneous access.
I am guessing that the stuff is extracted from a computing course, where the teacher is illustrating what goes wrong, when you don't have any mechanism for dealing with multiple simultaneous access. You suggest that the second attempt to store the value would fail, but the diagram explicitly says it succeeds (and stores the wrong value).
Presumably, he will then go on to explain what can be done in such situations (transaction services etc.).
Joined: Oct 30, 2001
Perhaps, to avoid getting confused about computer resources and concepts, one should think about this in everyday terms.
Salesman Alan goes to warehouse and sees there are 10 Acme Super Widgets in stock.
Salesman Bert goes to warehouse shortly after and sees there are 10 Acme Super Widgets in stock.
Alan visits a client and takes orders for 4 Super Widgets.
Bert independently visits another client and takes orders for 5 Super Widgets.
Alan returns to the warehouse and records the new stock level as 6, that being the 10 there were initially, minus the 4 he sold.
Bert returns later to the warehouse and records the new stock level as 5, that being the 10 there were initially, minus the 5 he sold. He doesn't know about the 4 that Alan sold.
There is really only one Super Widget left, but the stock system says there are 5.
You could fix such a problem by things like: -
Employ a storeman whose job it is to manage the stocks. Only one person can talk to him at once, or
Only allow one salesman to sell Super Widgets at any time, or
Joined: Sep 06, 2007
according to diagram:
1-value of A is 10 2-value is 10 3-value changes to 11,in step 3 4-value is 11 5-value become 12 .in step 5,becuase in step 5 one adds to A.
No, in step 5 Application A is incrementing its local copy of Variable A, not the shared resource Variable A. That is, Application A got the value of variable A from the shared resource in step 1. As far as Application A knows, the value of Variable A is 10. In step 5, Application A isn't going to check that value again to discover that it's 11, because as far as Application A knows, it just did that. Application A doesn't know what Application B is doing.
By the way, whoever wrote this example and used A as the name of both an application and a variable should be shot. They also would have been better off giving different names to the local copies of Variable A. [ October 18, 2007: Message edited by: Jim Yingst ]