For what it's worth, I pretty much agree with what Victor has been saying
in this exchange, so I'll let him carry the conversation.
It seems that what you're trying to say is that some thread will be
scheduled. This is simpler than a fairness guarantee, but it's still a
statement about scheduling. As the discussion demonstrates such statements
require new modes of reasoning and new modeling techniques. I don't think
it should be pursued.
At 09:03 AM 5/17/2004, Victor Luchangco wrote:
>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