[
https://issues.apache.org/jira/browse/LUCENE-9001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16947428#comment-16947428
]
Adrien Grand commented on LUCENE-9001:
--------------------------------------
When SetOnce was initially designed, I suspect it wasn't envisioned that one
would try to catch the exception since the goal was to signal a programming
error. That said, your proposal helps make it less surprising so it's probably
a good think to do anyway. I'll give others a couple days to comment in case
they think we should rather keep the current way that SetOnce works.
Do you need the trySet semantics? I wonder because if I needed them, I'd
probably go to AtomicReference directly instead of SetOnce, like we do in
IndexWriter. So I'd rather keep SetOnce simple and not introduce trySet.
> Race condition in SetOnce
> -------------------------
>
> Key: LUCENE-9001
> URL: https://issues.apache.org/jira/browse/LUCENE-9001
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Przemko Robakowski
> Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There is race condition in SetOnce that can cause code below fail with
> NullPointerException:
> {code:java}
> SetOnce<String> setOnce = new SetOnce<>();
> new Thread(() -> setOnce.set("thread")).start();
> try{
> setOnce.set("main");
> } catch (SetOnce.AlreadySetException e){
> setOnce.get().hashCode(); //possible NPE!
> }
> {code}
> This is caused by 2 separate write operations - 1 for set marker field and 1
> for actual object. So it's possible that marker is already set to true
> (causing AlreadySetException on second write attempt) but object is still not
> set (causing NullPointerException).
> This can be avoided by using single AtomicReference instead to serve both
> purposes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
