thread safety of java.lang.reflect.Field

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

thread safety of java.lang.reflect.Field

JSR166 Concurrency mailing list
Hello,

I wonder if instances of java.lang.reflect.Field can be shared between
multiple threads as long as the accessibility flag is either not modified
or modified exactly once prior to a safe publication of the field
instances.

In other words, is it legal to cache instances of j.l.r.Field between
multiple threads?

Best Regards,
Novi


PS: The Bean Validation reference implementation Hibernate Validator seems
to cache instances of j.l.r.Field across threads. However, I couldn't find  
any
clue in the Java API documentation whether such a usage is supported or
not.
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: thread safety of java.lang.reflect.Field

JSR166 Concurrency mailing list
I usually cache Fields in private static final fields in the class that
I use the Fields.  I have not had any trouble with multiple threads
using Fields concurrently.  One caution is that if two threads execute
the statement below concurrently on the same "obj", then one of the
increments could be lost.  In other words, one still has to be mindful
of concurrent access to the object's fields.

s_field.setInt(obj, s_field.getInt(obj) + 1);

-Nathan

On 5/31/2018 3:31 AM, Novi via Concurrency-interest wrote:

> Hello,
>
> I wonder if instances of java.lang.reflect.Field can be shared between
> multiple threads as long as the accessibility flag is either not modified
> or modified exactly once prior to a safe publication of the field
> instances.
>
> In other words, is it legal to cache instances of j.l.r.Field between
> multiple threads?
>
> Best Regards,
> Novi
>
>
> PS: The Bean Validation reference implementation Hibernate Validator
> seems
> to cache instances of j.l.r.Field across threads. However, I couldn't
> find any
> clue in the Java API documentation whether such a usage is supported or
> not.
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

--
-Nathan

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: thread safety of java.lang.reflect.Field

JSR166 Concurrency mailing list
> I have not had any trouble with multiple threads using Fields  
> concurrently.

Neither do I but that is no guarantee for correctness.
(Compare for example this reflection related issue:
https://bugs.openjdk.java.net/browse/JDK-8062771)


> In other words, one still has to be mindful of concurrent access to the  
> object's fields.

That is true but it is not what I meant to ask.


Assuming that j.l.r.Field is thread safe in the current OpenJDK version,  
is this
merely an implementation detail or something that is guaranteed in future
and/or other JVM implementations?

-Novi


Am 31.05.2018, 14:11 Uhr, schrieb Nathan and Ila Reynolds via
Concurrency-interest <[hidden email]>:

> I usually cache Fields in private static final fields in the class that  
> I use the Fields.  I have not had any trouble with multiple threads  
> using Fields concurrently.  One caution is that if two threads execute  
> the statement below concurrently on the same "obj", then one of the  
> increments could be lost.  In other words, one still has to be mindful  
> of concurrent access to the object's fields.
>
> s_field.setInt(obj, s_field.getInt(obj) + 1);
>
> -Nathan
>
> On 5/31/2018 3:31 AM, Novi via Concurrency-interest wrote:
>> Hello,
>>
>> I wonder if instances of java.lang.reflect.Field can be shared between
>> multiple threads as long as the accessibility flag is either not  
>> modified
>> or modified exactly once prior to a safe publication of the field
>> instances.
>>
>> In other words, is it legal to cache instances of j.l.r.Field between
>> multiple threads?
>>
>> Best Regards,
>> Novi
>>
>>
>> PS: The Bean Validation reference implementation Hibernate Validator  
>> seems
>> to cache instances of j.l.r.Field across threads. However, I couldn't  
>> find any
>> clue in the Java API documentation whether such a usage is supported or
>> not.
>> _______________________________________________
>> Concurrency-interest mailing list
>> [hidden email]
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: thread safety of java.lang.reflect.Field

JSR166 Concurrency mailing list
I can't speak for the standard, but caching Fields instances in static
fields is *very* common so it's unlikely they would ever change the
current behavior (it being safe to use).

If you are still concerned about correctness, VarHandle is specified to
be "immutable and have no visible state" so that would be safe to share
across threads.

- Jonas

On 2018-05-31 16:35, Novi via Concurrency-interest wrote:

>> I have not had any trouble with multiple threads using Fields
>> concurrently.
>
> Neither do I but that is no guarantee for correctness.
> (Compare for example this reflection related issue:
> https://bugs.openjdk.java.net/browse/JDK-8062771)
>
>
>> In other words, one still has to be mindful of concurrent access to
>> the object's fields.
>
> That is true but it is not what I meant to ask.
>
>
> Assuming that j.l.r.Field is thread safe in the current OpenJDK version,
> is this
> merely an implementation detail or something that is guaranteed in future
> and/or other JVM implementations?
>
> -Novi
>
>
> Am 31.05.2018, 14:11 Uhr, schrieb Nathan and Ila Reynolds via
> Concurrency-interest <[hidden email]>:
>
>> I usually cache Fields in private static final fields in the class
>> that I use the Fields.  I have not had any trouble with multiple
>> threads using Fields concurrently.  One caution is that if two threads
>> execute the statement below concurrently on the same "obj", then one
>> of the increments could be lost.  In other words, one still has to be
>> mindful of concurrent access to the object's fields.
>>
>> s_field.setInt(obj, s_field.getInt(obj) + 1);
>>
>> -Nathan
>>
>> On 5/31/2018 3:31 AM, Novi via Concurrency-interest wrote:
>>> Hello,
>>>
>>> I wonder if instances of java.lang.reflect.Field can be shared between
>>> multiple threads as long as the accessibility flag is either not
>>> modified
>>> or modified exactly once prior to a safe publication of the field
>>> instances.
>>>
>>> In other words, is it legal to cache instances of j.l.r.Field between
>>> multiple threads?
>>>
>>> Best Regards,
>>> Novi
>>>
>>>
>>> PS: The Bean Validation reference implementation Hibernate Validator
>>> seems
>>> to cache instances of j.l.r.Field across threads. However, I couldn't
>>> find any
>>> clue in the Java API documentation whether such a usage is supported or
>>> not.
>>> _______________________________________________
>>> Concurrency-interest mailing list
>>> [hidden email]
>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: thread safety of java.lang.reflect.Field

JSR166 Concurrency mailing list
----- Mail original -----
> De: "concurrency-interest" <[hidden email]>
> À: "concurrency-interest" <[hidden email]>
> Envoyé: Jeudi 31 Mai 2018 20:33:02
> Objet: Re: [concurrency-interest] thread safety of java.lang.reflect.Field

> I can't speak for the standard, but caching Fields instances in static
> fields is *very* common so it's unlikely they would ever change the
> current behavior (it being safe to use).
>
> If you are still concerned about correctness, VarHandle is specified to
> be "immutable and have no visible state" so that would be safe to share
> across threads.

I suppose you means MethodHandle, VarHandle are specialized method handles (almost*) for the different semantics when accessing a field.

* VarHandle are not MethodHandle because when you access a field, you can not throw checked exceptions (invoking a method handle throws Throwable).

>
> - Jonas

Rémi


>
> On 2018-05-31 16:35, Novi via Concurrency-interest wrote:
>>> I have not had any trouble with multiple threads using Fields
>>> concurrently.
>>
>> Neither do I but that is no guarantee for correctness.
>> (Compare for example this reflection related issue:
>> https://bugs.openjdk.java.net/browse/JDK-8062771)
>>
>>
>>> In other words, one still has to be mindful of concurrent access to
>>> the object's fields.
>>
>> That is true but it is not what I meant to ask.
>>
>>
>> Assuming that j.l.r.Field is thread safe in the current OpenJDK version,
>> is this
>> merely an implementation detail or something that is guaranteed in future
>> and/or other JVM implementations?
>>
>> -Novi
>>
>>
>> Am 31.05.2018, 14:11 Uhr, schrieb Nathan and Ila Reynolds via
>> Concurrency-interest <[hidden email]>:
>>
>>> I usually cache Fields in private static final fields in the class
>>> that I use the Fields.  I have not had any trouble with multiple
>>> threads using Fields concurrently.  One caution is that if two threads
>>> execute the statement below concurrently on the same "obj", then one
>>> of the increments could be lost.  In other words, one still has to be
>>> mindful of concurrent access to the object's fields.
>>>
>>> s_field.setInt(obj, s_field.getInt(obj) + 1);
>>>
>>> -Nathan
>>>
>>> On 5/31/2018 3:31 AM, Novi via Concurrency-interest wrote:
>>>> Hello,
>>>>
>>>> I wonder if instances of java.lang.reflect.Field can be shared between
>>>> multiple threads as long as the accessibility flag is either not
>>>> modified
>>>> or modified exactly once prior to a safe publication of the field
>>>> instances.
>>>>
>>>> In other words, is it legal to cache instances of j.l.r.Field between
>>>> multiple threads?
>>>>
>>>> Best Regards,
>>>> Novi
>>>>
>>>>
>>>> PS: The Bean Validation reference implementation Hibernate Validator
>>>> seems
>>>> to cache instances of j.l.r.Field across threads. However, I couldn't
>>>> find any
>>>> clue in the Java API documentation whether such a usage is supported or
>>>> not.
>>>> _______________________________________________
>>>> Concurrency-interest mailing list
>>>> [hidden email]
>>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>> _______________________________________________
>> Concurrency-interest mailing list
>> [hidden email]
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: thread safety of java.lang.reflect.Field

JSR166 Concurrency mailing list
In reply to this post by JSR166 Concurrency mailing list
The java.lang.reflect classes are not specified to be thread-safe. They probably should be specified that way but they aren't.

The implementation is quite complex in places and it is hard to determine whether they are thread-safe in practice. I can see some initialization race conditions with caching of field state (like getGenericInfo()) that theoretically could expose default rather than actual values.

David

> -----Original Message-----
> From: Concurrency-interest <[hidden email]> On Behalf Of Novi via Concurrency-interest
> Sent: Thursday, May 31, 2018 7:31 PM
> To: [hidden email]
> Subject: [concurrency-interest] thread safety of java.lang.reflect.Field
>
> Hello,
>
> I wonder if instances of java.lang.reflect.Field can be shared between multiple threads as long as the accessibility flag is either not
> modified or modified exactly once prior to a safe publication of the field instances.
>
> In other words, is it legal to cache instances of j.l.r.Field between multiple threads?
>
> Best Regards,
> Novi
>
>
> PS: The Bean Validation reference implementation Hibernate Validator seems to cache instances of j.l.r.Field across threads.
> However, I couldn't find any clue in the Java API documentation whether such a usage is supported or not.
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: thread safety of java.lang.reflect.Field

JSR166 Concurrency mailing list
> The java.lang.reflect classes are not specified to be thread-safe. They  
> probably should be specified that way but they aren't.

Do you see any chance that this is changed in future JDK releases?

-Novi


Am 01.06.2018, 00:55 Uhr, schrieb David Holmes <[hidden email]>:

> The java.lang.reflect classes are not specified to be thread-safe. They  
> probably should be specified that way but they aren't.
>
> The implementation is quite complex in places and it is hard to  
> determine whether they are thread-safe in practice. I can see some  
> initialization race conditions with caching of field state (like  
> getGenericInfo()) that theoretically could expose default rather than  
> actual values.
>
> David
>
>> -----Original Message-----
>> From: Concurrency-interest <[hidden email]>  
>> On Behalf Of Novi via Concurrency-interest
>> Sent: Thursday, May 31, 2018 7:31 PM
>> To: [hidden email]
>> Subject: [concurrency-interest] thread safety of java.lang.reflect.Field
>>
>> Hello,
>>
>> I wonder if instances of java.lang.reflect.Field can be shared between  
>> multiple threads as long as the accessibility flag is either not
>> modified or modified exactly once prior to a safe publication of the  
>> field instances.
>>
>> In other words, is it legal to cache instances of j.l.r.Field between  
>> multiple threads?
>>
>> Best Regards,
>> Novi
>>
>>
>> PS: The Bean Validation reference implementation Hibernate Validator  
>> seems to cache instances of j.l.r.Field across threads.
>> However, I couldn't find any clue in the Java API documentation whether  
>> such a usage is supported or not.
>> _______________________________________________
>> Concurrency-interest mailing list
>> [hidden email]
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: thread safety of java.lang.reflect.Field

JSR166 Concurrency mailing list
Novi writes:
> dholmes writes:
> > The java.lang.reflect classes are not specified to be thread-safe.
> > They probably should be specified that way but they aren't.
>
> Do you see any chance that this is changed in future JDK releases?

It seems unlikely given a number of thread-safety issues have been fixed over the years, yet no change to actual specification. See for example the relatively recent:

https://bugs.openjdk.java.net/browse/JDK-8064391

David
 

> -Novi
>
>
> Am 01.06.2018, 00:55 Uhr, schrieb David Holmes <[hidden email]>:
>
> > The java.lang.reflect classes are not specified to be thread-safe.
> > They probably should be specified that way but they aren't.
> >
> > The implementation is quite complex in places and it is hard to
> > determine whether they are thread-safe in practice. I can see some
> > initialization race conditions with caching of field state (like
> > getGenericInfo()) that theoretically could expose default rather than
> > actual values.
> >
> > David
> >
> >> -----Original Message-----
> >> From: Concurrency-interest
> >> <[hidden email]>
> >> On Behalf Of Novi via Concurrency-interest
> >> Sent: Thursday, May 31, 2018 7:31 PM
> >> To: [hidden email]
> >> Subject: [concurrency-interest] thread safety of
> >> java.lang.reflect.Field
> >>
> >> Hello,
> >>
> >> I wonder if instances of java.lang.reflect.Field can be shared
> >> between multiple threads as long as the accessibility flag is either
> >> not modified or modified exactly once prior to a safe publication of
> >> the field instances.
> >>
> >> In other words, is it legal to cache instances of j.l.r.Field between
> >> multiple threads?
> >>
> >> Best Regards,
> >> Novi
> >>
> >>
> >> PS: The Bean Validation reference implementation Hibernate Validator
> >> seems to cache instances of j.l.r.Field across threads.
> >> However, I couldn't find any clue in the Java API documentation
> >> whether such a usage is supported or not.
> >> _______________________________________________
> >> Concurrency-interest mailing list
> >> [hidden email]
> >> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest