Re: switch using strings
Peter Duniho wrote:
The problem is that each time the variable "counter" is reassigned, you get a
new object. In other words, as soon as it gets reassigned, you're dealing with
a whole new monitor for the purpose of the "synchronized" statement.
So, thread 1 acquires the lock, thread 2 waits for the lock, thread 1 updates
the counter, thread 3 calls increment(): bang! Thread 2 and thread 3 now are
both executing the code inside the supposedly "synchronized" block in the
increment() method.
Personally I find Lew's opinion on the matter to be over-stated. Yes, there's
Depends on how much you think I stated. All I said was that I don't find it
useful (it only saves a few characters of typing), and that it's dangerous on
the evidence. And that consequently I prefer not to use it.
Wow. Strong stuff. Better rein it in, huh?
a hazard. But in reality, there are _lots_ of hazards related to concurrent
programming; auto-boxing offers other conveniences that outweigh whatever
minor concerns its presence creates in the concurrent APIs.
(And frankly, the supposed null reference scenario mentioned earlier is
silly???as pointed out, that's simply a programmer error that could just as
easily occur without auto-boxing; the problem will show up the first time
someone tries to run the code, and is not difficult to figure out and fix).
But opinions vary, obviously. :)
You are absolutely correct. The example was trivial, not tied to autoboxing
particularly, and perfectly scaled for someone who was apparently unwilling to
do the research.
And certainly started a conversation that led to all sorts of useful links,
concrete and much, much better examples than mine, and hours of entertainment.
Oh, and utter vindication of my original, overstated point:
Autoboxing isn't all that useful. It has dangers. I prefer not to use it.
HTH.
--
Lew
Honi soit qui mal y pense.