lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tomás Fernández Löbbe (JIRA) <j...@apache.org>
Subject [jira] [Commented] (SOLR-11782) LatchWatcher.await doesn’t protect against spurious wakeup
Date Fri, 26 Jan 2018 22:08:00 GMT

    [ https://issues.apache.org/jira/browse/SOLR-11782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16341665#comment-16341665
] 

Tomás Fernández Löbbe commented on SOLR-11782:
----------------------------------------------

I see. I thought that could be the case, but wasn't sure, since the javadocs don't say that
explicitly, and they also say:
{code}
This method is behaviorally equivalent to: <pre> {@code awaitNanos(unit.toNanos(time))
> 0}</pre>
{code}
This makes the await method simpler, I can just do:
{code}
public void await(long timeoutMs) throws InterruptedException {
      lock.lock();
      try {
        if (this.event != null) {
          return;
        }
        eventReceived.await(timeoutMs, TimeUnit.MILLISECONDS);
      } finally {
        lock.unlock();
      }
    }
{code}

> LatchWatcher.await doesn’t protect against spurious wakeup
> ----------------------------------------------------------
>
>                 Key: SOLR-11782
>                 URL: https://issues.apache.org/jira/browse/SOLR-11782
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Tomás Fernández Löbbe
>            Assignee: Tomás Fernández Löbbe
>            Priority: Minor
>             Fix For: master (8.0), 7.3
>
>         Attachments: SOLR-11782.patch, SOLR-11782.patch, SOLR-11782.patch
>
>
> I noticed that {{LatchWatcher.await}} does:
> {code}
> public void await(long timeout) throws InterruptedException {
>       synchronized (lock) {
>         if (this.event != null) return;
>         lock.wait(timeout);
>       }
>     }
> {code}
> while the recommendation of lock.wait is to check the wait condition even after the method
returns in case of spurious wakeup. {{lock}} is a private local field to which {{notifyAll}}
is called only after a zk event is being handled. I think we should check the {{await}} method
to something like:
> {code}
> public void await(long timeout) throws InterruptedException {
>       assert timeout > 0;
>       long timeoutTime = System.currentTimeMillis() + timeout;
>       synchronized (lock) {
>         while (this.event == null) {
>           long nextTimeout = timeoutTime - System.currentTimeMillis();
>           if (nextTimeout <= 0) {
>             return;
>           }
>           lock.wait(nextTimeout);
>         }
>       }
>     }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message