On May 17, 2004, at 12:03 PM, Victor Luchangco wrote:
>> 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
>
The JMM treats thread execution as a black box.
It sees read actions (and provides the values seen
from shared memory), write actions and synchronization
actions. The only thing the JMM needs to know about
the internal actions is the ability to consult
an intra-thread semantics oracle to ensure that the
thread is behaving correctly.
Bill
-------------------------------
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