At 5:44 AM -0800 11/8/99, Joseph Bowbeer wrote:
>These terms certainly have a fractal-like boundary, but these terms do not
>come to mind when I think of James Gosling (*), Patrick Chan, the JINI
>developers, Josh Bloch (before he read the fine print), and the other
>admirable Java experts who, judging by their code, are not (or were not) aware
>of the possibility of per-thread-caching and the other details of the JMM that
>make writing correct concurrent code so hard to do.
After having been burned myself coming up with tricks that I thought
would allow me avoid synchronization while being guaranteed to work
under certain memory models, I consider myself naive.
>
>If you just focus on the concurrent code written by Java experts ("general"
>Java experts, that is: not concurrent programming experts), and if you just
>focus on the concurrent code that actually works today on most JVMs, then I
>think you *can* draw a box. In that box, there is no per-thread-caching. In
>that box objects are as visible as their references. That box is a tricky, but
>not an unreasonably harsh environment for programmers.
Can you explain this model a little more? What do you mean by saying
that there is no per-thread caching? That sounds like sequential
consistency.
>
>I claim that the problem is not that one can't draw a box, but that this box
>can't be implemented efficiently on SMP's with weak memory models. To emulate
>this box on some hardware may require memory barriers around every
>instruction, or it may even prevent more than one thread from running at a
>time, with each thread flushing its working memory as it is pre-empted.
>
>Actually, my claim is only that there is such a box. Whether this box can be
>implemented efficiently on SMP's, I leave for the SMP experts to decide.
I would agree that sequential consistency is a simple box. But I
think the cost of enforcing sequential consistency will be
prohibitive, even on a uniprocessor with a strong memory model, due
to interactions with the compiler.
We could consider adopting a model that would slow down Java
execution speeds by a factor of 2-3, but I don't think people would
be happy with such a model.
Bill
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:21 EDT