Does an object always see its latest internal state irrespective of thread?Does a finally block always get...

Important Resources for Dark Age Civilizations?

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

Is it legal for company to use my work email to pretend I still work there?

Replacing matching entries in one column of a file by another column from a different file

Is it possible to run Internet Explorer on OS X El Capitan?

Rock identification in KY

How much of data wrangling is a data scientist's job?

Is it possible to do 50 km distance without any previous training?

RSA: Danger of using p to create q

Why can't I see bouncing of switch on oscilloscope screen?

What are the disadvantages of having a left skewed distribution?

Why are electrically insulating heatsinks so rare? Is it just cost?

A case of the sniffles

DC-DC converter from low voltage at high current, to high voltage at low current

Malformed Address '10.10.21.08/24', must be X.X.X.X/NN or

Why is consensus so controversial in Britain?

Accidentally leaked the solution to an assignment, what to do now? (I'm the prof)

Horror movie about a virus at the prom; beginning and end are stylized as a cartoon

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

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

Can I ask the recruiters in my resume to put the reason why I am rejected?

Why "Having chlorophyll without photosynthesis is actually very dangerous" and "like living with a bomb"?

NMaximize is not converging to a solution

Has there ever been an airliner design involving reducing generator load by installing solar panels?



Does an 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 executionsMultiple 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 ScheduledExecutorServiceHow to implement a singleThreadedScheduledExcecutor in wildfly






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










share|improve this question

























  • Nope; most definitely not.

    – Boris the Spider
    5 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
    5 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, the object is accessing its own internal state inside of different threads (reading and incrementing). Is this code thread-safe or is it possible that we lose updates to the count variable when it's scheduled in a different thread?










share|improve this question

























  • Nope; most definitely not.

    – Boris the Spider
    5 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
    5 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, the object is accessing its own internal state inside of different threads (reading and incrementing). Is this code thread-safe or is it possible that we lose updates to the 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, the object is accessing its own internal state inside of different threads (reading and incrementing). Is this code thread-safe or is it possible that we lose updates to the 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








edited 53 mins ago









Peter Mortensen

13.9k1987113




13.9k1987113










asked 5 hours ago









RandomQuestionRandomQuestion

3,055144579




3,055144579













  • Nope; most definitely not.

    – Boris the Spider
    5 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
    5 hours ago





















  • Nope; most definitely not.

    – Boris the Spider
    5 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
    5 hours ago



















Nope; most definitely not.

– Boris the Spider
5 hours ago





Nope; most definitely not.

– Boris the Spider
5 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
5 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
5 hours ago














3 Answers
3






active

oldest

votes


















3














Does an 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


























  • Thank you for pointing out this happens-before guarantee about ScheduledThreadPoolExecutor.

    – RandomQuestion
    1 hour ago



















5














No, this code is not thread-safe because there isn't any happens-before relation between increments made in different threads started with ScheduledExecutorService.



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



UPDATE:



As @BoristheSpider mentioned, in general in case of increment/decrement making a 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
    5 hours ago













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

    – Sotirios Delimanolis
    4 hours 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
    4 hours 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
    4 hours ago











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

    – Sotirios Delimanolis
    3 hours ago



















2














No, this code is not thread-safe since there isn't any 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
    5 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
    5 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
    5 hours ago













  • @RandomQuestion yes. Because visibility.

    – Boris the Spider
    5 hours ago








  • 1





    @RandomQuestion To reiterate, the code you have posted is thread-safe. This answer is wrong.

    – Sotirios Delimanolis
    3 hours ago












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-an-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














Does an 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


























  • Thank you for pointing out this happens-before guarantee about ScheduledThreadPoolExecutor.

    – RandomQuestion
    1 hour ago
















3














Does an 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


























  • Thank you for pointing out this happens-before guarantee about ScheduledThreadPoolExecutor.

    – RandomQuestion
    1 hour ago














3












3








3







Does an 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 an 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 51 mins ago









Peter Mortensen

13.9k1987113




13.9k1987113










answered 4 hours ago









Sotirios DelimanolisSotirios Delimanolis

213k41500590




213k41500590













  • Thank you for pointing out this happens-before guarantee about ScheduledThreadPoolExecutor.

    – RandomQuestion
    1 hour ago



















  • Thank you for pointing out this happens-before guarantee about ScheduledThreadPoolExecutor.

    – RandomQuestion
    1 hour ago

















Thank you for pointing out this happens-before guarantee about ScheduledThreadPoolExecutor.

– RandomQuestion
1 hour ago





Thank you for pointing out this happens-before guarantee about ScheduledThreadPoolExecutor.

– RandomQuestion
1 hour ago













5














No, this code is not thread-safe because there isn't any happens-before relation between increments made in different threads started with ScheduledExecutorService.



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



UPDATE:



As @BoristheSpider mentioned, in general in case of increment/decrement making a 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
    5 hours ago













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

    – Sotirios Delimanolis
    4 hours 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
    4 hours 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
    4 hours ago











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

    – Sotirios Delimanolis
    3 hours ago
















5














No, this code is not thread-safe because there isn't any happens-before relation between increments made in different threads started with ScheduledExecutorService.



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



UPDATE:



As @BoristheSpider mentioned, in general in case of increment/decrement making a 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
    5 hours ago













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

    – Sotirios Delimanolis
    4 hours 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
    4 hours 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
    4 hours ago











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

    – Sotirios Delimanolis
    3 hours ago














5












5








5







No, this code is not thread-safe because there isn't any happens-before relation between increments made in different threads started with ScheduledExecutorService.



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



UPDATE:



As @BoristheSpider mentioned, in general in case of increment/decrement making a 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 isn't any happens-before relation between increments made in different threads started with ScheduledExecutorService.



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



UPDATE:



As @BoristheSpider mentioned, in general in case of increment/decrement making a 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 46 mins ago









Peter Mortensen

13.9k1987113




13.9k1987113










answered 5 hours ago









IvanIvan

5,70411022




5,70411022













  • @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
    5 hours ago













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

    – Sotirios Delimanolis
    4 hours 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
    4 hours 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
    4 hours ago











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

    – Sotirios Delimanolis
    3 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
    5 hours ago













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

    – Sotirios Delimanolis
    4 hours 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
    4 hours 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
    4 hours ago











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

    – Sotirios Delimanolis
    3 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
5 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
5 hours ago















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

– Sotirios Delimanolis
4 hours ago





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

– Sotirios Delimanolis
4 hours 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
4 hours 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
4 hours 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
4 hours 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
4 hours ago













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

– Sotirios Delimanolis
3 hours ago





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

– Sotirios Delimanolis
3 hours ago











2














No, this code is not thread-safe since there isn't any 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
    5 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
    5 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
    5 hours ago













  • @RandomQuestion yes. Because visibility.

    – Boris the Spider
    5 hours ago








  • 1





    @RandomQuestion To reiterate, the code you have posted is thread-safe. This answer is wrong.

    – Sotirios Delimanolis
    3 hours ago
















2














No, this code is not thread-safe since there isn't any 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
    5 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
    5 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
    5 hours ago













  • @RandomQuestion yes. Because visibility.

    – Boris the Spider
    5 hours ago








  • 1





    @RandomQuestion To reiterate, the code you have posted is thread-safe. This answer is wrong.

    – Sotirios Delimanolis
    3 hours ago














2












2








2







No, this code is not thread-safe since there isn't any happens before relation between different threads accessing count.






share|improve this answer















No, this code is not thread-safe since there isn't any happens before relation between different threads accessing count.







share|improve this answer














share|improve this answer



share|improve this answer








edited 50 mins ago









Peter Mortensen

13.9k1987113




13.9k1987113










answered 5 hours ago









michidmichid

5,54921938




5,54921938








  • 1





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

    – Andy Turner
    5 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
    5 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
    5 hours ago













  • @RandomQuestion yes. Because visibility.

    – Boris the Spider
    5 hours ago








  • 1





    @RandomQuestion To reiterate, the code you have posted is thread-safe. This answer is wrong.

    – Sotirios Delimanolis
    3 hours ago














  • 1





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

    – Andy Turner
    5 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
    5 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
    5 hours ago













  • @RandomQuestion yes. Because visibility.

    – Boris the Spider
    5 hours ago








  • 1





    @RandomQuestion To reiterate, the code you have posted is thread-safe. This answer is wrong.

    – Sotirios Delimanolis
    3 hours ago








1




1





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

– Andy Turner
5 hours ago





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

– Andy Turner
5 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
5 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
5 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
5 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
5 hours ago















@RandomQuestion yes. Because visibility.

– Boris the Spider
5 hours ago







@RandomQuestion yes. Because visibility.

– Boris the Spider
5 hours ago






1




1





@RandomQuestion To reiterate, the code you have posted is thread-safe. This answer is wrong.

– Sotirios Delimanolis
3 hours ago





@RandomQuestion To reiterate, the code you have posted is thread-safe. This answer is wrong.

– Sotirios Delimanolis
3 hours ago


















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-an-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

Why do type traits not work with types in namespace scope?What are POD types in C++?Why can templates only be...

Will tsunami waves travel forever if there was no land?Why do tsunami waves begin with the water flowing away...

Simple Scan not detecting my scanner (Brother DCP-7055W)Brother MFC-L2700DW printer can print, can't...