On Fri, 16 Jun 2023 01:21:57 GMT, Weijun Wang <wei...@openjdk.org> wrote:
> The `attributes` field inside the `PKCS12KeyStore.Entry` class might be
> modified and retrieved at the same time. Make it concurrent.
>
> The test uses some reflection to get this field and try updating it in
> multiple threads.
src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1438:
> 1436:
> 1437: if (entry.attributes == null) {
> 1438: entry.attributes = ConcurrentHashMap.newKeySet();
It seems that there is still a risk that two threads may compete here, then you
may end up with one thread working with a different copy of the attributes, no
longer tied to the entry. E.g:
Thread#1 sees attributes is null, Thread#2 sees attributes is null, both set
attributes and only one of them win. The caller in the second thread (that
lost) is given the "dangling" map that has not been set, and if it modifies it
then modifications will be lost.
I don't know if this scenario can actually happen - but the possibility is
there. Unless there's always some locking further up the stack that would
prevent this?
Also I see in total four places that do:
[entry|this].attributes = new HashSet<>();
wouldn't you need to modify all four places in the same manner?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/14506#discussion_r1232011194
