Re: Integer 128 != Integer 128 ??
On 10/13/2010 12:23 AM, Peter Duniho wrote:
Daniel Pitts wrote:
Its not the synchronized statement that boxing affected, its the ++
statement. count is a *different* reference every time
"incrementCount" gets called, and therefore two threads may see
different values of count inside the synchronize block. They will
indeed become less likely to properly synchronize over time.
Ah, right. I'm not sure what "over time" has to do with it. And the
problem could be mitigated by compiler, run-time, and hardware
optimizations (i.e. the field isn't "volatile" and so even after it's
been updated in one thread, another thread might still see the
out-of-date value, the reference that's being used for synchronization).
But yes, I see the problem in the code now.
For posterity, the correct approach is to use an AtomicInteger.
I'd say that's _a_ correct approach. It would also be fine to
synchronize on a different object, and even to do so while storing the
integer value in an actual "int" instead of boxing it.
Right. I don't recall the original questioner saying much about
the genesis of his problem, but I harbored the suspicion that he might
have begun with
static int count = 0;
...
synchronized(count) { count++; }
The compiler, naturally, would have objected. So I suspect he cast
around a bit and discovered that
static Integer count = 0;
...
synchronized(count) { count++; }
made the error message go away. Had he done this before auto-boxing
was inflicted on the suffering world, he'd instead have encountered
two more error messages, one for the attempt to initialize an Integer
with an int, and one for trying to apply the ++ operator to an object
reference. Those messages would not have solved his problem either,
of course, but at least they would have let him know he was still in
trouble and that it wasn't time to declare victory and move on.
Auto-boxing isn't syntactic sugar; it's syntactic saccharine:
sweet, but devoid of nutritional value.
--
Eric Sosman
esosman@ieee-dot-org.invalid