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;
}
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
add a comment |
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
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, Supposecount==N
. Then along comes worker thread A, which setscount = N+1
. Then one whole second later, worker thread B is chosen to call therun()
method, and worker thread B looks atcount
. It is possible at that point for worker thread B to still seecount == N
.
– Solomon Slow
5 hours ago
add a comment |
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
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
java multithreading concurrency
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, Supposecount==N
. Then along comes worker thread A, which setscount = N+1
. Then one whole second later, worker thread B is chosen to call therun()
method, and worker thread B looks atcount
. It is possible at that point for worker thread B to still seecount == N
.
– Solomon Slow
5 hours ago
add a comment |
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, Supposecount==N
. Then along comes worker thread A, which setscount = N+1
. Then one whole second later, worker thread B is chosen to call therun()
method, and worker thread B looks atcount
. It is possible at that point for worker thread B to still seecount == 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
add a comment |
3 Answers
3
active
oldest
votes
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
orscheduleWithFixedDelay
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.
Thank you for pointing out this happens-before guarantee aboutScheduledThreadPoolExecutor
.
– RandomQuestion
1 hour ago
add a comment |
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.
@BoristheSpider taking into account howscheduleWithFixedDelay
work there will be no overlapped calls tocounter++
in that particular scenario. Sovolatile
should be OK.
– Ivan
5 hours ago
There is a happens-before relation introduced between subsequent execution of a task scheduled withscheduleWithFixedDelay
.
– Sotirios Delimanolis
4 hours ago
How comevolatile
is not enough? The semantics ofvolatile
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 casevolatile
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
add a comment |
No, this code is not thread-safe since there isn't any happens before relation between different threads accessing count
.
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'tcounter++
be synchronized too as increment operation is not atomic.
– Yug Singh
5 hours ago
1
Doescounter++
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
|
show 2 more comments
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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
orscheduleWithFixedDelay
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.
Thank you for pointing out this happens-before guarantee aboutScheduledThreadPoolExecutor
.
– RandomQuestion
1 hour ago
add a comment |
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
orscheduleWithFixedDelay
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.
Thank you for pointing out this happens-before guarantee aboutScheduledThreadPoolExecutor
.
– RandomQuestion
1 hour ago
add a comment |
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
orscheduleWithFixedDelay
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.
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
orscheduleWithFixedDelay
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.
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 aboutScheduledThreadPoolExecutor
.
– RandomQuestion
1 hour ago
add a comment |
Thank you for pointing out this happens-before guarantee aboutScheduledThreadPoolExecutor
.
– 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
add a comment |
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.
@BoristheSpider taking into account howscheduleWithFixedDelay
work there will be no overlapped calls tocounter++
in that particular scenario. Sovolatile
should be OK.
– Ivan
5 hours ago
There is a happens-before relation introduced between subsequent execution of a task scheduled withscheduleWithFixedDelay
.
– Sotirios Delimanolis
4 hours ago
How comevolatile
is not enough? The semantics ofvolatile
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 casevolatile
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
add a comment |
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.
@BoristheSpider taking into account howscheduleWithFixedDelay
work there will be no overlapped calls tocounter++
in that particular scenario. Sovolatile
should be OK.
– Ivan
5 hours ago
There is a happens-before relation introduced between subsequent execution of a task scheduled withscheduleWithFixedDelay
.
– Sotirios Delimanolis
4 hours ago
How comevolatile
is not enough? The semantics ofvolatile
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 casevolatile
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
add a comment |
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.
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.
edited 46 mins ago
Peter Mortensen
13.9k1987113
13.9k1987113
answered 5 hours ago
IvanIvan
5,70411022
5,70411022
@BoristheSpider taking into account howscheduleWithFixedDelay
work there will be no overlapped calls tocounter++
in that particular scenario. Sovolatile
should be OK.
– Ivan
5 hours ago
There is a happens-before relation introduced between subsequent execution of a task scheduled withscheduleWithFixedDelay
.
– Sotirios Delimanolis
4 hours ago
How comevolatile
is not enough? The semantics ofvolatile
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 casevolatile
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
add a comment |
@BoristheSpider taking into account howscheduleWithFixedDelay
work there will be no overlapped calls tocounter++
in that particular scenario. Sovolatile
should be OK.
– Ivan
5 hours ago
There is a happens-before relation introduced between subsequent execution of a task scheduled withscheduleWithFixedDelay
.
– Sotirios Delimanolis
4 hours ago
How comevolatile
is not enough? The semantics ofvolatile
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 casevolatile
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
add a comment |
No, this code is not thread-safe since there isn't any happens before relation between different threads accessing count
.
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'tcounter++
be synchronized too as increment operation is not atomic.
– Yug Singh
5 hours ago
1
Doescounter++
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
|
show 2 more comments
No, this code is not thread-safe since there isn't any happens before relation between different threads accessing count
.
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'tcounter++
be synchronized too as increment operation is not atomic.
– Yug Singh
5 hours ago
1
Doescounter++
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
|
show 2 more comments
No, this code is not thread-safe since there isn't any happens before relation between different threads accessing count
.
No, this code is not thread-safe since there isn't any happens before relation between different threads accessing count
.
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'tcounter++
be synchronized too as increment operation is not atomic.
– Yug Singh
5 hours ago
1
Doescounter++
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
|
show 2 more comments
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'tcounter++
be synchronized too as increment operation is not atomic.
– Yug Singh
5 hours ago
1
Doescounter++
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
|
show 2 more comments
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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 setscount = N+1
. Then one whole second later, worker thread B is chosen to call therun()
method, and worker thread B looks atcount
. It is possible at that point for worker thread B to still seecount == N
.– Solomon Slow
5 hours ago