[
https://issues.apache.org/jira/browse/LUCENE-9453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17175294#comment-17175294
]
Dawid Weiss commented on LUCENE-9453:
-------------------------------------
I believe it might have been left out intentionally. A reentrant lock is fairly
cheap but still adds overhead. If this method is private and called from under
monitors already then this would be sufficient to ensure correctness (and
eliminate any extra monitor overhead):
assert Thread.holdsLock(this) : "This method should never be called without a
lock!";
> DocumentWriterFlushControl missing explicit sync on write
> ---------------------------------------------------------
>
> Key: LUCENE-9453
> URL: https://issues.apache.org/jira/browse/LUCENE-9453
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/index
> Reporter: Mike Drob
> Priority: Trivial
> Time Spent: 10m
> Remaining Estimate: 0h
>
> checkoutAndBlock is not synchronized, but has a non-atomic write to
> {{numPending}}. Meanwhile, all of the other writes to numPending are in sync
> methods.
> In this case it turns out to be ok because all of the code paths calling this
> method are already sync:
> {{synchronized doAfterDocument -> checkout -> checkoutAndBlock}}
> {{checkoutLargestNonPendingWriter -> synchronized(this) -> checkout ->
> checkoutAndBlock}}
> If we make {{synchronized checkoutAndBlock}} that protects us against future
> changes, shouldn't cause any performance impact since the code paths will
> already be going through a sync block, and will make an IntelliJ warning go
> away.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
