[concurrency-interest] Java Memory Model versus dotnet MemoryModel
brian at quiotix.com
Sun Nov 6 13:00:35 EST 2005
> Should we worry about multicores soon to be
I think what Serge is getting at here is that the fact that
single-processor machines have been the norm in a lot of environments,
especially on desktops, has masked a lot of bugs, which may soon be
unmasked as the MP machines become cheaper and more widespread.
This is true, but I think a bigger masking factor is the dominance of
IA32 in the low-end multiprocessor world, whose stronger memory model
also masks a lot of real concurrency bugs.
> There are millions of them currently running.
And most are stateless, another masking factor. The servlets that are
most likely to show thread-safety problems are also those that are most
likely to show other logic errors, such as those that implicitly assume
that the user will never hit the "back" button. These are the ones that
carry state from request to request.
In other words, yes, the increased chance that a program will be
deployed on an MP system will disclose more bugs. But there is a lot of
"noise" that may continue to mask these bugs, so I doubt it will be the
flood that some predict. It might be better if it were a flood, because
then people would take it seriously (and some of us on this list could
make a fortune cashing in on the "next Y2K panic".)
> A large portion of them are currently running on
> uniprocessors and probably most of these are slated to
> be ported to multicore systems over the next few
Except that there will be no "porting", just redeploying. Porting
involves a managed effort to audit, modify, and test. More likely,
people will buy new systems and slap them in their racks.
> What is the expected percentage of these that will
> show new defects when ported to multicore?
> I am worried by this but maybe I shouldn't be.
> Nevertheless, there are quite a few signals raising
> alarms about the issue of concurrent Java code ported
> from uniprocessors to multicore and I hope that this
> mailing list will be helpful about it, as I think it
> is part of its purpose.
> Thank you for all who make this list so informative
> and useful.
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
More information about the Concurrency-interest