[concurrency-interest] Interesting story from Dave Dice

Péter Kovács peter.kovacs.1.0rc at gmail.com
Mon May 25 11:27:45 EDT 2009

I have to retract my previous mail. I see that the write-back feature
is even mentioned in the Tech Tips article. Apart from the awkward
name for this JNI constant, it appears to be a pure operator error not
to use JNI_ABORT for an immutable array.


2009/5/25 Péter Kovács <peter.kovacs.1.0rc at gmail.com>:
> It is certainly rather subjective who finds what surprising. :-) To
> me, the surprising part is that you cannot read without subsequently
> writing back.
> Thanks
> Peter
> On Mon, May 25, 2009 at 12:46 PM, David Holmes <davidcholmes at aapt.net.au> wrote:
>> Peter Kovacs writes:
>>> 1. If an operation/class/method/whatever is not declared to be
>>> thread-safe, you can assume it is not. Correct? (If it is declared to
>>> be so, you can, perhaps, be optimistic and assume it is.)
>>> 2. If a variable (an array in this case) is written to, the variable
>>> is not "effectively immutable". (Probably useless of nitpicking on the
>>> meaning of "effectively".)
>>> Is this really novel?
>> I think this certainly violates the principle of least surprise. If you just
>> want to _read_ an array from native code, then there are no specific methods
>> for that, you have to use these JNI methods that assume you want to write to
>> the array as well. Even realizing that these are potentially mutating
>> methods, I still find it surprising that writing back the same values that
>> you read is not guaranteed to be seen correctly. Looking at what actually
>> happens I can go "Oh I see, yes that makes sense" - but there's no way I
>> would have thought of that happening before-hand.
>> David Holmes

More information about the Concurrency-interest mailing list