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

[David Holmes]

This time really adding Doug Lea :)

On 11/02/2015 11:43 AM, David Holmes wrote:
> 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.
>>