Bill Pugh wrote:
> This could work. However, we would need to describe
> the circumstances under which a thread is allowed to perform
> an infinite sequence of "internal actions". We need to avoid
> a Zeno's paradox of a thread performing an infinite number
> of "internal actions" in order to accomplish a finite amount
> of work.
I don't understand the problem here. We must have some
connection between the execution and the program, and
the program presumably specifies whether it does some
externally observable action in the midst of its
internal actions. So this requirement seems like it
should fall out of the "intra-thread semantics".
> It also complicates things because people might think you need
> to reason about these actions in cases other than that of a
> non-terminating execution. With an infiniteLoop action, it is clear
> that it only comes into play in the case of a thread that has
> gone into an internal infinite loop.
I disagree. I think it's simpler because everything
a thread does corresponds to some action. Without
internal actions, we have to fold changes in the
internal states of threads into their external actions.
The reason it's not such a problem is that the JMM
spec sweeps all those under the rug of intra-thread
semantics (which is appropriate). As long as the
internal state changes are straightforward, then
you can just ignore the internal actions. But if
you need to think something through carefully, you
may need to know about the internal state, and then
you'll need the internal actions. That's why all
the formal models of concurrency include internal
actions--it makes them easier, not harder, to use.
Victor
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:07 EDT