Unsafe.park/unpark, j.u.c.LockSupport and Thread

[David Holmes]

Adding Doug Lea.

On 11/02/2015 12:51 AM, Paul Sandoz wrote:
> On Feb 10, 2015, at 3:39 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>>>
>>> Adding native methods to 166 classes will introduce another form of dependency on the platform that i would prefer to avoid.
>>
>> Right. And I suspect that the separate distributable of 166, outside of the Java Platform, would not want to have to carry a separate platform specific native library.
>
> Yes.

Right and for that reason jsr166 distribution would not want to have to 
know whether to use Thread or Unsafe.

>
>>
>>>> But I don't see any reason why we couldn't move the implementation from unsafe.cpp to jvm.cpp and invoke via a native method implementation of LockSupport. It would still be just as "unsafe" of course.
>>>>
>>>
>>> Can you think of any reasons, beyond that of "don't touch the core classes", why we cannot copy this functionality over to java.lang.{*, Thread} ?
>>
>> Would you be thinking of making the changes public, i.e. new standard API on java.lang.Thread ?
>>
>
> Yes, j.l.Thread seems like the ideal location :-)

I don't see any point in moving it to Thread now. The public supported 
API already exists in LockSupport. As I said you'd have to deprecate it 
in 9 with an intent to remove in 10 - assuming you are even allowed to 
do that.

The issue is not LockSupport versus Thread, but the use of Unsafe.

David


> Paul.
>