Does object always see its latest internal state irrespective of thread?Does a finally block always get executed in Java?Java: serial thread confinement questionJava difference between fixed threadpool and scheduled threadpoolJackrabbit and concurrent modificationHow to stop a Runnable scheduled for repeated execution after a certain number of executionsvolatile keyword for objects in C++Multiple threads accessing inner classHow can a loop be completed by two thread? say loop from count=1 to count=4 by ist thread and count =5 to 8 by 2nd thread?If I keep a reference to a Runnable, when does the Thread it ran on get released?How to stop a schedule ScheduledExecutorService

Are astronomers waiting to see something in an image from a gravitational lens that they've already seen in an adjacent image?

Maximum likelihood parameters deviate from posterior distributions

Uncaught TypeError: 'set' on proxy: trap returned falsish for property Name

NMaximize is not converging to a solution

Rock identification in KY

Revoked SSL certificate

Client team has low performances and low technical skills: we always fix their work and now they stop collaborate with us. How to solve?

How to move a thin line with the black arrow in Illustrator?

What would happen to a modern skyscraper if it rains micro blackholes?

expand `ifthenelse` immediately

How do I deal with an unproductive colleague in a small company?

What typically incentivizes a professor to change jobs to a lower ranking university?

Why is Minecraft giving an OpenGL error?

Convert two switches to a dual stack, and add outlet - possible here?

When a company launches a new product do they "come out" with a new product or do they "come up" with a new product?

What's that red-plus icon near a text?

How does Bumblebee speak English as soon as he arrives on Earth in the Bumblebee movie?

How much RAM could one put in a typical 80386 setup?

What does it mean to describe someone as a butt steak?

Can you really stack all of this on an Opportunity Attack?

Mortgage Pre-approval / Loan - Apply Alone or with Fiancée?

A newer friend of my brother's gave him a load of baseball cards that are supposedly extremely valuable. Is this a scam?

Is it inappropriate for a student to attend their mentor's dissertation defense?

Today is the Center



Does object always see its latest internal state irrespective of thread?


Does a finally block always get executed in Java?Java: serial thread confinement questionJava difference between fixed threadpool and scheduled threadpoolJackrabbit and concurrent modificationHow to stop a Runnable scheduled for repeated execution after a certain number of executionsvolatile keyword for objects in C++Multiple threads accessing inner classHow can a loop be completed by two thread? say loop from count=1 to count=4 by ist thread and count =5 to 8 by 2nd thread?If I keep a reference to a Runnable, when does the Thread it ran on get released?How to stop a schedule ScheduledExecutorService






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;








8















Let's say I have a runnable with a simple integer count variable which is incremented every time runnable runs. One instance of this object is submitted to run periodically in a scheduled executor service.



class Counter implements Runnable 
private int count = 0;

@Override
public void run()
count++;



Counter counter = new Counter();
ScheduledExecutorService executorService = Executors.newScheduledThreadPool(5);
executorService.scheduleWithFixedDelay(counter, 1, 1, TimeUnit.SECONDS);


Here, object is accessing its own internal state inside of different threads (reading and incrementing). Is this code thread safe or it's possible that we lose updates to count variable when it's scheduled in a different thread?










share|improve this question






















  • Nope; most definitely not.

    – Boris the Spider
    2 hours ago






  • 3





    Just to be clear: When the answers below say "...no happens-before..." what they're saying is, Suppose count==N. Then along comes worker thread A, which sets count = N+1. Then one whole second later, worker thread B is chosen to call the run() method, and worker thread B looks at count. It is possible at that point for worker thread B to still see count == N.

    – Solomon Slow
    2 hours ago


















8















Let's say I have a runnable with a simple integer count variable which is incremented every time runnable runs. One instance of this object is submitted to run periodically in a scheduled executor service.



class Counter implements Runnable 
private int count = 0;

@Override
public void run()
count++;



Counter counter = new Counter();
ScheduledExecutorService executorService = Executors.newScheduledThreadPool(5);
executorService.scheduleWithFixedDelay(counter, 1, 1, TimeUnit.SECONDS);


Here, object is accessing its own internal state inside of different threads (reading and incrementing). Is this code thread safe or it's possible that we lose updates to count variable when it's scheduled in a different thread?










share|improve this question






















  • Nope; most definitely not.

    – Boris the Spider
    2 hours ago






  • 3





    Just to be clear: When the answers below say "...no happens-before..." what they're saying is, Suppose count==N. Then along comes worker thread A, which sets count = N+1. Then one whole second later, worker thread B is chosen to call the run() method, and worker thread B looks at count. It is possible at that point for worker thread B to still see count == N.

    – Solomon Slow
    2 hours ago














8












8








8


2






Let's say I have a runnable with a simple integer count variable which is incremented every time runnable runs. One instance of this object is submitted to run periodically in a scheduled executor service.



class Counter implements Runnable 
private int count = 0;

@Override
public void run()
count++;



Counter counter = new Counter();
ScheduledExecutorService executorService = Executors.newScheduledThreadPool(5);
executorService.scheduleWithFixedDelay(counter, 1, 1, TimeUnit.SECONDS);


Here, object is accessing its own internal state inside of different threads (reading and incrementing). Is this code thread safe or it's possible that we lose updates to count variable when it's scheduled in a different thread?










share|improve this question














Let's say I have a runnable with a simple integer count variable which is incremented every time runnable runs. One instance of this object is submitted to run periodically in a scheduled executor service.



class Counter implements Runnable 
private int count = 0;

@Override
public void run()
count++;



Counter counter = new Counter();
ScheduledExecutorService executorService = Executors.newScheduledThreadPool(5);
executorService.scheduleWithFixedDelay(counter, 1, 1, TimeUnit.SECONDS);


Here, object is accessing its own internal state inside of different threads (reading and incrementing). Is this code thread safe or it's possible that we lose updates to count variable when it's scheduled in a different thread?







java multithreading concurrency






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked 2 hours ago









RandomQuestionRandomQuestion

3,055144579




3,055144579












  • Nope; most definitely not.

    – Boris the Spider
    2 hours ago






  • 3





    Just to be clear: When the answers below say "...no happens-before..." what they're saying is, Suppose count==N. Then along comes worker thread A, which sets count = N+1. Then one whole second later, worker thread B is chosen to call the run() method, and worker thread B looks at count. It is possible at that point for worker thread B to still see count == N.

    – Solomon Slow
    2 hours ago


















  • Nope; most definitely not.

    – Boris the Spider
    2 hours ago






  • 3





    Just to be clear: When the answers below say "...no happens-before..." what they're saying is, Suppose count==N. Then along comes worker thread A, which sets count = N+1. Then one whole second later, worker thread B is chosen to call the run() method, and worker thread B looks at count. It is possible at that point for worker thread B to still see count == N.

    – Solomon Slow
    2 hours ago

















Nope; most definitely not.

– Boris the Spider
2 hours ago





Nope; most definitely not.

– Boris the Spider
2 hours ago




3




3





Just to be clear: When the answers below say "...no happens-before..." what they're saying is, Suppose count==N. Then along comes worker thread A, which sets count = N+1. Then one whole second later, worker thread B is chosen to call the run() method, and worker thread B looks at count. It is possible at that point for worker thread B to still see count == N.

– Solomon Slow
2 hours ago






Just to be clear: When the answers below say "...no happens-before..." what they're saying is, Suppose count==N. Then along comes worker thread A, which sets count = N+1. Then one whole second later, worker thread B is chosen to call the run() method, and worker thread B looks at count. It is possible at that point for worker thread B to still see count == N.

– Solomon Slow
2 hours ago













3 Answers
3






active

oldest

votes


















3














No this code is not thread-safe because there is no happens-before relation between increments made in different threads started with ScheduledExecutorService.



To fix it you need to either mark variable as volatile or switch to AtomicInteger or AtomicLong.



UPDATE:
As @BoristheSpider mentioned, in general in case of increment/decrement making variable volatile is not enough since increment/decrement is not atomic itself and calling it from several threads concurrently will cause race conditions and missed updates. However in this particular case scheduleWithFixedDelay() guarantees (according to Javadoc) that there will be overlapping executions of scheduled task so volatile will also work in this particular case even with increment.






share|improve this answer

























  • @BoristheSpider taking into account how scheduleWithFixedDelay work there will be no overlapped calls to counter++ in that particular scenario. So volatile should be OK.

    – Ivan
    2 hours ago












  • There is a happens-before relation introduced between subsequent execution of a task scheduled with scheduleWithFixedDelay.

    – Sotirios Delimanolis
    1 hour ago











  • How come volatile is not enough? The semantics of volatile should hold in every case and it would solve this problem. In the past, the writing of doubles and longs could have been more difficult to do atomically since those occupied more than one 32-bit register. However, as far as I can tell, that should not affect the semantics of volatile. Or am I missing something?

    – Edwin Dalorzo
    1 hour ago











  • @EdwinDalorzo in this particular case volatile is enough. But in general case not because increment is effectively translated into 3 operations: read, add, write and is prone to race condition in multithreaded environment

    – Ivan
    1 hour ago











  • To reiterate, the code they have posted is thread-safe. This answer is wrong.

    – Sotirios Delimanolis
    21 mins ago


















2














No this is code is not thread safe since there is no happens before relation between different threads accessing count.






share|improve this answer




















  • 1





    Even then it's not thread safe, because ++ isn't atomic.

    – Andy Turner
    2 hours ago






  • 1





    @michid please correct me if I am wrong but shouldn't counter++ be synchronized too as increment operation is not atomic.

    – Yug Singh
    2 hours ago






  • 1





    Does counter++ need to be synchronized even if it's guaranteed that only one thread will be running this runnable at a time (like in the code in the question)?

    – RandomQuestion
    2 hours ago












  • @RandomQuestion yes. Because visibility.

    – Boris the Spider
    2 hours ago












  • I agree with the comments here that accesses to counter++ should be synchronized and that merely declaring it volatile is not sufficient. I edited my answer accordingly focusing on the happens-before relation.

    – michid
    2 hours ago


















0














Does object always see its latest internal state irrespective of thread?



Just to be clear for the purposes of this question and its answers, an object doesn't do anything, it's just memory. Threads are the executing entity. It's misleading to say does an object see whatever. It's the thread that's doing the seeing/reading of object state.



This isn't specified in the javadoc, but



Executors.newScheduledThreadPool(5);


returns a ScheduledThreadPoolExecutor.



Your code is using



executorService.scheduleWithFixedDelay(counter, 1, 1, TimeUnit.SECONDS);


The javadoc for ScheduledThreadPoolExecutor#scheduledWithFixedDelay states




Submits a periodic action that becomes enabled first after the given
initial delay, and subsequently with the given delay between the
termination of one execution and the commencement of the next.




The class javadoc further clarifies




Successive executions of a periodic task scheduled via
scheduleAtFixedRate or scheduleWithFixedDelay do not overlap.
While different executions may be performed by different threads, the
effects of prior executions happen-before those of subsequent ones
.




As such, each execution of Counter#run is guaranteed to see the value of count after it's been incremented by the previous execution. For example, the third execution will read a count value of 2 before it performs its increment.



You don't need volatile or any other additional synchronization mechanism for this specific use case.






share|improve this answer

























    Your Answer






    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: "1"
    ;
    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',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader:
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    ,
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );













    draft saved

    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55542189%2fdoes-object-always-see-its-latest-internal-state-irrespective-of-thread%23new-answer', 'question_page');

    );

    Post as a guest















    Required, but never shown

























    3 Answers
    3






    active

    oldest

    votes








    3 Answers
    3






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    3














    No this code is not thread-safe because there is no happens-before relation between increments made in different threads started with ScheduledExecutorService.



    To fix it you need to either mark variable as volatile or switch to AtomicInteger or AtomicLong.



    UPDATE:
    As @BoristheSpider mentioned, in general in case of increment/decrement making variable volatile is not enough since increment/decrement is not atomic itself and calling it from several threads concurrently will cause race conditions and missed updates. However in this particular case scheduleWithFixedDelay() guarantees (according to Javadoc) that there will be overlapping executions of scheduled task so volatile will also work in this particular case even with increment.






    share|improve this answer

























    • @BoristheSpider taking into account how scheduleWithFixedDelay work there will be no overlapped calls to counter++ in that particular scenario. So volatile should be OK.

      – Ivan
      2 hours ago












    • There is a happens-before relation introduced between subsequent execution of a task scheduled with scheduleWithFixedDelay.

      – Sotirios Delimanolis
      1 hour ago











    • How come volatile is not enough? The semantics of volatile should hold in every case and it would solve this problem. In the past, the writing of doubles and longs could have been more difficult to do atomically since those occupied more than one 32-bit register. However, as far as I can tell, that should not affect the semantics of volatile. Or am I missing something?

      – Edwin Dalorzo
      1 hour ago











    • @EdwinDalorzo in this particular case volatile is enough. But in general case not because increment is effectively translated into 3 operations: read, add, write and is prone to race condition in multithreaded environment

      – Ivan
      1 hour ago











    • To reiterate, the code they have posted is thread-safe. This answer is wrong.

      – Sotirios Delimanolis
      21 mins ago















    3














    No this code is not thread-safe because there is no happens-before relation between increments made in different threads started with ScheduledExecutorService.



    To fix it you need to either mark variable as volatile or switch to AtomicInteger or AtomicLong.



    UPDATE:
    As @BoristheSpider mentioned, in general in case of increment/decrement making variable volatile is not enough since increment/decrement is not atomic itself and calling it from several threads concurrently will cause race conditions and missed updates. However in this particular case scheduleWithFixedDelay() guarantees (according to Javadoc) that there will be overlapping executions of scheduled task so volatile will also work in this particular case even with increment.






    share|improve this answer

























    • @BoristheSpider taking into account how scheduleWithFixedDelay work there will be no overlapped calls to counter++ in that particular scenario. So volatile should be OK.

      – Ivan
      2 hours ago












    • There is a happens-before relation introduced between subsequent execution of a task scheduled with scheduleWithFixedDelay.

      – Sotirios Delimanolis
      1 hour ago











    • How come volatile is not enough? The semantics of volatile should hold in every case and it would solve this problem. In the past, the writing of doubles and longs could have been more difficult to do atomically since those occupied more than one 32-bit register. However, as far as I can tell, that should not affect the semantics of volatile. Or am I missing something?

      – Edwin Dalorzo
      1 hour ago











    • @EdwinDalorzo in this particular case volatile is enough. But in general case not because increment is effectively translated into 3 operations: read, add, write and is prone to race condition in multithreaded environment

      – Ivan
      1 hour ago











    • To reiterate, the code they have posted is thread-safe. This answer is wrong.

      – Sotirios Delimanolis
      21 mins ago













    3












    3








    3







    No this code is not thread-safe because there is no happens-before relation between increments made in different threads started with ScheduledExecutorService.



    To fix it you need to either mark variable as volatile or switch to AtomicInteger or AtomicLong.



    UPDATE:
    As @BoristheSpider mentioned, in general in case of increment/decrement making variable volatile is not enough since increment/decrement is not atomic itself and calling it from several threads concurrently will cause race conditions and missed updates. However in this particular case scheduleWithFixedDelay() guarantees (according to Javadoc) that there will be overlapping executions of scheduled task so volatile will also work in this particular case even with increment.






    share|improve this answer















    No this code is not thread-safe because there is no happens-before relation between increments made in different threads started with ScheduledExecutorService.



    To fix it you need to either mark variable as volatile or switch to AtomicInteger or AtomicLong.



    UPDATE:
    As @BoristheSpider mentioned, in general in case of increment/decrement making variable volatile is not enough since increment/decrement is not atomic itself and calling it from several threads concurrently will cause race conditions and missed updates. However in this particular case scheduleWithFixedDelay() guarantees (according to Javadoc) that there will be overlapping executions of scheduled task so volatile will also work in this particular case even with increment.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited 2 hours ago

























    answered 2 hours ago









    IvanIvan

    5,69911022




    5,69911022












    • @BoristheSpider taking into account how scheduleWithFixedDelay work there will be no overlapped calls to counter++ in that particular scenario. So volatile should be OK.

      – Ivan
      2 hours ago












    • There is a happens-before relation introduced between subsequent execution of a task scheduled with scheduleWithFixedDelay.

      – Sotirios Delimanolis
      1 hour ago











    • How come volatile is not enough? The semantics of volatile should hold in every case and it would solve this problem. In the past, the writing of doubles and longs could have been more difficult to do atomically since those occupied more than one 32-bit register. However, as far as I can tell, that should not affect the semantics of volatile. Or am I missing something?

      – Edwin Dalorzo
      1 hour ago











    • @EdwinDalorzo in this particular case volatile is enough. But in general case not because increment is effectively translated into 3 operations: read, add, write and is prone to race condition in multithreaded environment

      – Ivan
      1 hour ago











    • To reiterate, the code they have posted is thread-safe. This answer is wrong.

      – Sotirios Delimanolis
      21 mins ago

















    • @BoristheSpider taking into account how scheduleWithFixedDelay work there will be no overlapped calls to counter++ in that particular scenario. So volatile should be OK.

      – Ivan
      2 hours ago












    • There is a happens-before relation introduced between subsequent execution of a task scheduled with scheduleWithFixedDelay.

      – Sotirios Delimanolis
      1 hour ago











    • How come volatile is not enough? The semantics of volatile should hold in every case and it would solve this problem. In the past, the writing of doubles and longs could have been more difficult to do atomically since those occupied more than one 32-bit register. However, as far as I can tell, that should not affect the semantics of volatile. Or am I missing something?

      – Edwin Dalorzo
      1 hour ago











    • @EdwinDalorzo in this particular case volatile is enough. But in general case not because increment is effectively translated into 3 operations: read, add, write and is prone to race condition in multithreaded environment

      – Ivan
      1 hour ago











    • To reiterate, the code they have posted is thread-safe. This answer is wrong.

      – Sotirios Delimanolis
      21 mins ago
















    @BoristheSpider taking into account how scheduleWithFixedDelay work there will be no overlapped calls to counter++ in that particular scenario. So volatile should be OK.

    – Ivan
    2 hours ago






    @BoristheSpider taking into account how scheduleWithFixedDelay work there will be no overlapped calls to counter++ in that particular scenario. So volatile should be OK.

    – Ivan
    2 hours ago














    There is a happens-before relation introduced between subsequent execution of a task scheduled with scheduleWithFixedDelay.

    – Sotirios Delimanolis
    1 hour ago





    There is a happens-before relation introduced between subsequent execution of a task scheduled with scheduleWithFixedDelay.

    – Sotirios Delimanolis
    1 hour ago













    How come volatile is not enough? The semantics of volatile should hold in every case and it would solve this problem. In the past, the writing of doubles and longs could have been more difficult to do atomically since those occupied more than one 32-bit register. However, as far as I can tell, that should not affect the semantics of volatile. Or am I missing something?

    – Edwin Dalorzo
    1 hour ago





    How come volatile is not enough? The semantics of volatile should hold in every case and it would solve this problem. In the past, the writing of doubles and longs could have been more difficult to do atomically since those occupied more than one 32-bit register. However, as far as I can tell, that should not affect the semantics of volatile. Or am I missing something?

    – Edwin Dalorzo
    1 hour ago













    @EdwinDalorzo in this particular case volatile is enough. But in general case not because increment is effectively translated into 3 operations: read, add, write and is prone to race condition in multithreaded environment

    – Ivan
    1 hour ago





    @EdwinDalorzo in this particular case volatile is enough. But in general case not because increment is effectively translated into 3 operations: read, add, write and is prone to race condition in multithreaded environment

    – Ivan
    1 hour ago













    To reiterate, the code they have posted is thread-safe. This answer is wrong.

    – Sotirios Delimanolis
    21 mins ago





    To reiterate, the code they have posted is thread-safe. This answer is wrong.

    – Sotirios Delimanolis
    21 mins ago













    2














    No this is code is not thread safe since there is no happens before relation between different threads accessing count.






    share|improve this answer




















    • 1





      Even then it's not thread safe, because ++ isn't atomic.

      – Andy Turner
      2 hours ago






    • 1





      @michid please correct me if I am wrong but shouldn't counter++ be synchronized too as increment operation is not atomic.

      – Yug Singh
      2 hours ago






    • 1





      Does counter++ need to be synchronized even if it's guaranteed that only one thread will be running this runnable at a time (like in the code in the question)?

      – RandomQuestion
      2 hours ago












    • @RandomQuestion yes. Because visibility.

      – Boris the Spider
      2 hours ago












    • I agree with the comments here that accesses to counter++ should be synchronized and that merely declaring it volatile is not sufficient. I edited my answer accordingly focusing on the happens-before relation.

      – michid
      2 hours ago















    2














    No this is code is not thread safe since there is no happens before relation between different threads accessing count.






    share|improve this answer




















    • 1





      Even then it's not thread safe, because ++ isn't atomic.

      – Andy Turner
      2 hours ago






    • 1





      @michid please correct me if I am wrong but shouldn't counter++ be synchronized too as increment operation is not atomic.

      – Yug Singh
      2 hours ago






    • 1





      Does counter++ need to be synchronized even if it's guaranteed that only one thread will be running this runnable at a time (like in the code in the question)?

      – RandomQuestion
      2 hours ago












    • @RandomQuestion yes. Because visibility.

      – Boris the Spider
      2 hours ago












    • I agree with the comments here that accesses to counter++ should be synchronized and that merely declaring it volatile is not sufficient. I edited my answer accordingly focusing on the happens-before relation.

      – michid
      2 hours ago













    2












    2








    2







    No this is code is not thread safe since there is no happens before relation between different threads accessing count.






    share|improve this answer















    No this is code is not thread safe since there is no happens before relation between different threads accessing count.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited 2 hours ago

























    answered 2 hours ago









    michidmichid

    5,54921938




    5,54921938







    • 1





      Even then it's not thread safe, because ++ isn't atomic.

      – Andy Turner
      2 hours ago






    • 1





      @michid please correct me if I am wrong but shouldn't counter++ be synchronized too as increment operation is not atomic.

      – Yug Singh
      2 hours ago






    • 1





      Does counter++ need to be synchronized even if it's guaranteed that only one thread will be running this runnable at a time (like in the code in the question)?

      – RandomQuestion
      2 hours ago












    • @RandomQuestion yes. Because visibility.

      – Boris the Spider
      2 hours ago












    • I agree with the comments here that accesses to counter++ should be synchronized and that merely declaring it volatile is not sufficient. I edited my answer accordingly focusing on the happens-before relation.

      – michid
      2 hours ago












    • 1





      Even then it's not thread safe, because ++ isn't atomic.

      – Andy Turner
      2 hours ago






    • 1





      @michid please correct me if I am wrong but shouldn't counter++ be synchronized too as increment operation is not atomic.

      – Yug Singh
      2 hours ago






    • 1





      Does counter++ need to be synchronized even if it's guaranteed that only one thread will be running this runnable at a time (like in the code in the question)?

      – RandomQuestion
      2 hours ago












    • @RandomQuestion yes. Because visibility.

      – Boris the Spider
      2 hours ago












    • I agree with the comments here that accesses to counter++ should be synchronized and that merely declaring it volatile is not sufficient. I edited my answer accordingly focusing on the happens-before relation.

      – michid
      2 hours ago







    1




    1





    Even then it's not thread safe, because ++ isn't atomic.

    – Andy Turner
    2 hours ago





    Even then it's not thread safe, because ++ isn't atomic.

    – Andy Turner
    2 hours ago




    1




    1





    @michid please correct me if I am wrong but shouldn't counter++ be synchronized too as increment operation is not atomic.

    – Yug Singh
    2 hours ago





    @michid please correct me if I am wrong but shouldn't counter++ be synchronized too as increment operation is not atomic.

    – Yug Singh
    2 hours ago




    1




    1





    Does counter++ need to be synchronized even if it's guaranteed that only one thread will be running this runnable at a time (like in the code in the question)?

    – RandomQuestion
    2 hours ago






    Does counter++ need to be synchronized even if it's guaranteed that only one thread will be running this runnable at a time (like in the code in the question)?

    – RandomQuestion
    2 hours ago














    @RandomQuestion yes. Because visibility.

    – Boris the Spider
    2 hours ago






    @RandomQuestion yes. Because visibility.

    – Boris the Spider
    2 hours ago














    I agree with the comments here that accesses to counter++ should be synchronized and that merely declaring it volatile is not sufficient. I edited my answer accordingly focusing on the happens-before relation.

    – michid
    2 hours ago





    I agree with the comments here that accesses to counter++ should be synchronized and that merely declaring it volatile is not sufficient. I edited my answer accordingly focusing on the happens-before relation.

    – michid
    2 hours ago











    0














    Does object always see its latest internal state irrespective of thread?



    Just to be clear for the purposes of this question and its answers, an object doesn't do anything, it's just memory. Threads are the executing entity. It's misleading to say does an object see whatever. It's the thread that's doing the seeing/reading of object state.



    This isn't specified in the javadoc, but



    Executors.newScheduledThreadPool(5);


    returns a ScheduledThreadPoolExecutor.



    Your code is using



    executorService.scheduleWithFixedDelay(counter, 1, 1, TimeUnit.SECONDS);


    The javadoc for ScheduledThreadPoolExecutor#scheduledWithFixedDelay states




    Submits a periodic action that becomes enabled first after the given
    initial delay, and subsequently with the given delay between the
    termination of one execution and the commencement of the next.




    The class javadoc further clarifies




    Successive executions of a periodic task scheduled via
    scheduleAtFixedRate or scheduleWithFixedDelay do not overlap.
    While different executions may be performed by different threads, the
    effects of prior executions happen-before those of subsequent ones
    .




    As such, each execution of Counter#run is guaranteed to see the value of count after it's been incremented by the previous execution. For example, the third execution will read a count value of 2 before it performs its increment.



    You don't need volatile or any other additional synchronization mechanism for this specific use case.






    share|improve this answer





























      0














      Does object always see its latest internal state irrespective of thread?



      Just to be clear for the purposes of this question and its answers, an object doesn't do anything, it's just memory. Threads are the executing entity. It's misleading to say does an object see whatever. It's the thread that's doing the seeing/reading of object state.



      This isn't specified in the javadoc, but



      Executors.newScheduledThreadPool(5);


      returns a ScheduledThreadPoolExecutor.



      Your code is using



      executorService.scheduleWithFixedDelay(counter, 1, 1, TimeUnit.SECONDS);


      The javadoc for ScheduledThreadPoolExecutor#scheduledWithFixedDelay states




      Submits a periodic action that becomes enabled first after the given
      initial delay, and subsequently with the given delay between the
      termination of one execution and the commencement of the next.




      The class javadoc further clarifies




      Successive executions of a periodic task scheduled via
      scheduleAtFixedRate or scheduleWithFixedDelay do not overlap.
      While different executions may be performed by different threads, the
      effects of prior executions happen-before those of subsequent ones
      .




      As such, each execution of Counter#run is guaranteed to see the value of count after it's been incremented by the previous execution. For example, the third execution will read a count value of 2 before it performs its increment.



      You don't need volatile or any other additional synchronization mechanism for this specific use case.






      share|improve this answer



























        0












        0








        0







        Does object always see its latest internal state irrespective of thread?



        Just to be clear for the purposes of this question and its answers, an object doesn't do anything, it's just memory. Threads are the executing entity. It's misleading to say does an object see whatever. It's the thread that's doing the seeing/reading of object state.



        This isn't specified in the javadoc, but



        Executors.newScheduledThreadPool(5);


        returns a ScheduledThreadPoolExecutor.



        Your code is using



        executorService.scheduleWithFixedDelay(counter, 1, 1, TimeUnit.SECONDS);


        The javadoc for ScheduledThreadPoolExecutor#scheduledWithFixedDelay states




        Submits a periodic action that becomes enabled first after the given
        initial delay, and subsequently with the given delay between the
        termination of one execution and the commencement of the next.




        The class javadoc further clarifies




        Successive executions of a periodic task scheduled via
        scheduleAtFixedRate or scheduleWithFixedDelay do not overlap.
        While different executions may be performed by different threads, the
        effects of prior executions happen-before those of subsequent ones
        .




        As such, each execution of Counter#run is guaranteed to see the value of count after it's been incremented by the previous execution. For example, the third execution will read a count value of 2 before it performs its increment.



        You don't need volatile or any other additional synchronization mechanism for this specific use case.






        share|improve this answer















        Does object always see its latest internal state irrespective of thread?



        Just to be clear for the purposes of this question and its answers, an object doesn't do anything, it's just memory. Threads are the executing entity. It's misleading to say does an object see whatever. It's the thread that's doing the seeing/reading of object state.



        This isn't specified in the javadoc, but



        Executors.newScheduledThreadPool(5);


        returns a ScheduledThreadPoolExecutor.



        Your code is using



        executorService.scheduleWithFixedDelay(counter, 1, 1, TimeUnit.SECONDS);


        The javadoc for ScheduledThreadPoolExecutor#scheduledWithFixedDelay states




        Submits a periodic action that becomes enabled first after the given
        initial delay, and subsequently with the given delay between the
        termination of one execution and the commencement of the next.




        The class javadoc further clarifies




        Successive executions of a periodic task scheduled via
        scheduleAtFixedRate or scheduleWithFixedDelay do not overlap.
        While different executions may be performed by different threads, the
        effects of prior executions happen-before those of subsequent ones
        .




        As such, each execution of Counter#run is guaranteed to see the value of count after it's been incremented by the previous execution. For example, the third execution will read a count value of 2 before it performs its increment.



        You don't need volatile or any other additional synchronization mechanism for this specific use case.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited 1 hour ago

























        answered 1 hour ago









        Sotirios DelimanolisSotirios Delimanolis

        212k41500590




        212k41500590



























            draft saved

            draft discarded
















































            Thanks for contributing an answer to Stack Overflow!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid


            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.

            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55542189%2fdoes-object-always-see-its-latest-internal-state-irrespective-of-thread%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            名間水力發電廠 目录 沿革 設施 鄰近設施 註釋 外部連結 导航菜单23°50′10″N 120°42′41″E / 23.83611°N 120.71139°E / 23.83611; 120.7113923°50′10″N 120°42′41″E / 23.83611°N 120.71139°E / 23.83611; 120.71139計畫概要原始内容臺灣第一座BOT 模式開發的水力發電廠-名間水力電廠名間水力發電廠 水利署首件BOT案原始内容《小檔案》名間電廠 首座BOT水力發電廠原始内容名間電廠BOT - 經濟部水利署中區水資源局

            Prove that NP is closed under karp reduction?Space(n) not closed under Karp reductions - what about NTime(n)?Class P is closed under rotation?Prove or disprove that $NL$ is closed under polynomial many-one reductions$mathbfNC_2$ is closed under log-space reductionOn Karp reductionwhen can I know if a class (complexity) is closed under reduction (cook/karp)Check if class $PSPACE$ is closed under polyonomially space reductionIs NPSPACE also closed under polynomial-time reduction and under log-space reduction?Prove PSPACE is closed under complement?Prove PSPACE is closed under union?

            Is my guitar’s action too high? Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern)Strings too stiff on a recently purchased acoustic guitar | Cort AD880CEIs the action of my guitar really high?Μy little finger is too weak to play guitarWith guitar, how long should I give my fingers to strengthen / callous?When playing a fret the guitar sounds mutedPlaying (Barre) chords up the guitar neckI think my guitar strings are wound too tight and I can't play barre chordsF barre chord on an SG guitarHow to find to the right strings of a barre chord by feel?High action on higher fret on my steel acoustic guitar