I would argue against this, for the following methodological reason.
Reasoning with HB is tricky and can introduce subtle bugs that are a
nightmare in the field.
Java should strongly encourage programmers desiring to communicate
reliably between threads to use explicit synchronization.
In this case, just declare the variable volatile. It also captures
design intent (that this variable is being used to communicate between
threads) for readers and maintainers of the code.
This is Java, not C -- defining the language because programmers might
"expect" something to be reasonable is a general recipe for introducing
guns, knives and clubs ... there must be good solid methodological
reasons for defining the language a particular way.
Best,
Vijay
Bill Pugh wrote:
>
> On Mar 17, 2004, at 5:33 PM, David Holmes wrote:
>
>>
>> I'm not sure I agree that this is necessary - or necessarily a good
>> thing.
>> The interrupt tells the thread to wakeup. Once the thread wakes up any
>> access to data shared between the interruptor and interruptee should be
>> correctly synchronized as normal.
>>
>> What you are proposing essentially amounts to making the "interrupted"
>> "field" of a thread behave as a volatile - right?
>>
>
> Yes. The idea is that someone might do something like
>
> * Interrupter thread
> - store some data as to why the thread is being interrupted
> - interrupt the thread
>
> * Interupted thread
> - receive interrupt
> - look at data explaining why it was interrupted.
>
> In general, I think any way of reliably communicating between threads
> should
> induce a happens-before edge. Certainly, I think programmers may
> expect that something
> like the above is reasonable.
> Bill
>
> -------------------------------
> JavaMemoryModel mailing list -
> http://www.cs.umd.edu/~pugh/java/memoryModel
>
>
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:00 EDT