Check for timeout in wait() loop

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;







up vote
1
down vote

favorite












I want to check for a condition in a guarded wait() loop with a user-specified total timeout, similar to how LinkedBlockingQueue.poll() works.



For example collection can be appended to by different threads, but only when the collection contains a value equating to myItem within timeout, should the loop terminate successfully. If the user-specified timeout elapses, it should throw.



This is my current best approach:



long startTime = System.currentTimeMillis();
synchronized (collection)
while (!collection.contains(myItem))
long remaining = System.currentTimeMillis() - startTime - timeout;
if (remaining < 0)
throw new TimeoutException();

collection.wait(remaining);




The problem here is that System.currentTimeMillis() (or System.nanoTime()) is called inside a synchronized context. IntelliJ's warning states:




While not necessarily representing a problem, such calls cause an expensive context switch, and are best kept out of synchronized contexts, if possible.




I wonder how much impact this 'expensive context switch' will have in practice, with Oracle JVM 8?




This is one alternative I came up with, but I don't like this as the actual timeout becomes ⌊timeout/10⌋*10 + delta. and the error will probably be much worse than the context switch.



synchronized (collection) 
int loops = 0;
while (!collection.contains(myItem))
if(loops++ > timeout / 10)
throw new TimeoutException();

collection.wait(10);








share|improve this question



























    up vote
    1
    down vote

    favorite












    I want to check for a condition in a guarded wait() loop with a user-specified total timeout, similar to how LinkedBlockingQueue.poll() works.



    For example collection can be appended to by different threads, but only when the collection contains a value equating to myItem within timeout, should the loop terminate successfully. If the user-specified timeout elapses, it should throw.



    This is my current best approach:



    long startTime = System.currentTimeMillis();
    synchronized (collection)
    while (!collection.contains(myItem))
    long remaining = System.currentTimeMillis() - startTime - timeout;
    if (remaining < 0)
    throw new TimeoutException();

    collection.wait(remaining);




    The problem here is that System.currentTimeMillis() (or System.nanoTime()) is called inside a synchronized context. IntelliJ's warning states:




    While not necessarily representing a problem, such calls cause an expensive context switch, and are best kept out of synchronized contexts, if possible.




    I wonder how much impact this 'expensive context switch' will have in practice, with Oracle JVM 8?




    This is one alternative I came up with, but I don't like this as the actual timeout becomes ⌊timeout/10⌋*10 + delta. and the error will probably be much worse than the context switch.



    synchronized (collection) 
    int loops = 0;
    while (!collection.contains(myItem))
    if(loops++ > timeout / 10)
    throw new TimeoutException();

    collection.wait(10);








    share|improve this question























      up vote
      1
      down vote

      favorite









      up vote
      1
      down vote

      favorite











      I want to check for a condition in a guarded wait() loop with a user-specified total timeout, similar to how LinkedBlockingQueue.poll() works.



      For example collection can be appended to by different threads, but only when the collection contains a value equating to myItem within timeout, should the loop terminate successfully. If the user-specified timeout elapses, it should throw.



      This is my current best approach:



      long startTime = System.currentTimeMillis();
      synchronized (collection)
      while (!collection.contains(myItem))
      long remaining = System.currentTimeMillis() - startTime - timeout;
      if (remaining < 0)
      throw new TimeoutException();

      collection.wait(remaining);




      The problem here is that System.currentTimeMillis() (or System.nanoTime()) is called inside a synchronized context. IntelliJ's warning states:




      While not necessarily representing a problem, such calls cause an expensive context switch, and are best kept out of synchronized contexts, if possible.




      I wonder how much impact this 'expensive context switch' will have in practice, with Oracle JVM 8?




      This is one alternative I came up with, but I don't like this as the actual timeout becomes ⌊timeout/10⌋*10 + delta. and the error will probably be much worse than the context switch.



      synchronized (collection) 
      int loops = 0;
      while (!collection.contains(myItem))
      if(loops++ > timeout / 10)
      throw new TimeoutException();

      collection.wait(10);








      share|improve this question













      I want to check for a condition in a guarded wait() loop with a user-specified total timeout, similar to how LinkedBlockingQueue.poll() works.



      For example collection can be appended to by different threads, but only when the collection contains a value equating to myItem within timeout, should the loop terminate successfully. If the user-specified timeout elapses, it should throw.



      This is my current best approach:



      long startTime = System.currentTimeMillis();
      synchronized (collection)
      while (!collection.contains(myItem))
      long remaining = System.currentTimeMillis() - startTime - timeout;
      if (remaining < 0)
      throw new TimeoutException();

      collection.wait(remaining);




      The problem here is that System.currentTimeMillis() (or System.nanoTime()) is called inside a synchronized context. IntelliJ's warning states:




      While not necessarily representing a problem, such calls cause an expensive context switch, and are best kept out of synchronized contexts, if possible.




      I wonder how much impact this 'expensive context switch' will have in practice, with Oracle JVM 8?




      This is one alternative I came up with, but I don't like this as the actual timeout becomes ⌊timeout/10⌋*10 + delta. and the error will probably be much worse than the context switch.



      synchronized (collection) 
      int loops = 0;
      while (!collection.contains(myItem))
      if(loops++ > timeout / 10)
      throw new TimeoutException();

      collection.wait(10);










      share|improve this question












      share|improve this question




      share|improve this question








      edited Jun 7 at 9:09
























      asked Jun 7 at 8:11









      Mark Jeronimus

      1865




      1865




















          1 Answer
          1






          active

          oldest

          votes

















          up vote
          0
          down vote













          I think you should be fine with System.currentTimeMillis(). Even though the method itself is not synchronized, mostly native method call internally would be synchronized.



          Read this old but still useful article about the same thing.



          http://www.devx.com/Java/Article/28685






          share|improve this answer





















            Your Answer




            StackExchange.ifUsing("editor", function ()
            return StackExchange.using("mathjaxEditing", function ()
            StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix)
            StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
            );
            );
            , "mathjax-editing");

            StackExchange.ifUsing("editor", function ()
            StackExchange.using("externalEditor", function ()
            StackExchange.using("snippets", function ()
            StackExchange.snippets.init();
            );
            );
            , "code-snippets");

            StackExchange.ready(function()
            var channelOptions =
            tags: "".split(" "),
            id: "196"
            ;
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function()
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled)
            StackExchange.using("snippets", function()
            createEditor();
            );

            else
            createEditor();

            );

            function createEditor()
            StackExchange.prepareEditor(
            heartbeatType: 'answer',
            convertImagesToLinks: false,
            noModals: false,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            );



            );








             

            draft saved


            draft discarded


















            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f196003%2fcheck-for-timeout-in-wait-loop%23new-answer', 'question_page');

            );

            Post as a guest






























            1 Answer
            1






            active

            oldest

            votes








            1 Answer
            1






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes








            up vote
            0
            down vote













            I think you should be fine with System.currentTimeMillis(). Even though the method itself is not synchronized, mostly native method call internally would be synchronized.



            Read this old but still useful article about the same thing.



            http://www.devx.com/Java/Article/28685






            share|improve this answer

























              up vote
              0
              down vote













              I think you should be fine with System.currentTimeMillis(). Even though the method itself is not synchronized, mostly native method call internally would be synchronized.



              Read this old but still useful article about the same thing.



              http://www.devx.com/Java/Article/28685






              share|improve this answer























                up vote
                0
                down vote










                up vote
                0
                down vote









                I think you should be fine with System.currentTimeMillis(). Even though the method itself is not synchronized, mostly native method call internally would be synchronized.



                Read this old but still useful article about the same thing.



                http://www.devx.com/Java/Article/28685






                share|improve this answer













                I think you should be fine with System.currentTimeMillis(). Even though the method itself is not synchronized, mostly native method call internally would be synchronized.



                Read this old but still useful article about the same thing.



                http://www.devx.com/Java/Article/28685







                share|improve this answer













                share|improve this answer



                share|improve this answer











                answered Jun 14 at 7:43









                Jabbar_Jigariyo

                22414




                22414






















                     

                    draft saved


                    draft discarded


























                     


                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function ()
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f196003%2fcheck-for-timeout-in-wait-loop%23new-answer', 'question_page');

                    );

                    Post as a guest













































































                    Popular posts from this blog

                    Greedy Best First Search implementation in Rust

                    Function to Return a JSON Like Objects Using VBA Collections and Arrays

                    C++11 CLH Lock Implementation