Full disclaimer: this is not really a homework, but I tagged it as such because it is mostly a self-learning exercise rather than actually "for work".
Let's say I want to write a simple thread safe modular counter in Java. That is, if the modulo M is 3, then the counter should cycle through 0, 1, 2, 0, 1, 2, … ad infinitum.
Here's one attempt:
import java.util.concurrent.atomic.AtomicInteger;
public class AtomicModularCounter {
private final AtomicInteger tick = new AtomicInteger();
private final int M;
public AtomicModularCounter(int M) {
this.M = M;
}
public int next() {
return modulo(tick.getAndIncrement(), M);
}
private final static int modulo(int v, int M) {
return ((v % M) + M) % M;
}
}
My analysis (which may be faulty) of this code is that since it uses AtomicInteger, it's quite thread safe even without any explicit synchronized method/block.
Unfortunately the "algorithm" itself doesn't quite "work", because when tick wraps around Integer.MAX_VALUE, next() may return the wrong value depending on the modulo M. That is:
System.out.println(Integer.MAX_VALUE + 1 == Integer.MIN_VALUE); // true
System.out.println(modulo(Integer.MAX_VALUE, 3)); // 1
System.out.println(modulo(Integer.MIN_VALUE, 3)); // 1
That is, two calls to next() will return 1, 1 when the modulo is 3 and tick wraps around.
There may also be an issue with next() getting out-of-order values, e.g.:
Thread1 calls next()
Thread2 calls next()
Thread2 completes tick.getAndIncrement(), returns x
Thread1 completes tick.getAndIncrement(), returns y = x+1 (mod M)
Here, barring the forementioned wrapping problem, x and y are indeed the two correct values to return for these two next() calls, but depending on how the counter behavior is specified, it can be argued that they're out of order. That is, we now have (Thread1, y) and (Thread2, x), but maybe it should really be specified that (Thread1, x) and (Thread2, y) is the "proper" behavior.
So by some definition of the words, AtomicModularCounter is thread-safe, but not actually atomic.
So the questions are:
Is my analysis correct? If not, then please point out any errors.
Is my last statement above using the correct terminology? If not, what is the correct statement?
If the problems mentioned above are real, then how would you fix it?
Can you fix it without using synchronized, by harnessing the atomicity of AtomicInteger?
How would you write it such that tick itself is range-controlled by the modulo and never even gets a chance to wraps over Integer.MAX_VALUE?
We can assume M is at least an order smaller than Integer.MAX_VALUE if necessary
Appendix
Here's a List analogy of the out-of-order "problem".
Thread1 calls add(first)
Thread2 calls add(second)
Now, if we have the list updated succesfully with two elements added, but second comes before first, which is at the end, is that "thread safe"?
If that is "thread safe", then what is it not? That is, if we specify that in the above scenario, first should always come before second, what is that concurrency property called? (I called it "atomicity" but I'm not sure if this is the correct terminology).
For what it's worth, what is the Collections.synchronizedList behavior with regards to this out-of-order aspect?
As far as I can see you just need a variation of the getAndIncrement() method
public final int getAndIncrement(int modulo) {
for (;;) {
int current = atomicInteger.get();
int next = (current + 1) % modulo;
if (atomicInteger.compareAndSet(current, next))
return current;
}
}
I would say that aside from the wrapping, it's fine. When two method calls are effectively simultaneous, you can't guarantee which will happen first.
The code is still atomic, because whichever actually happens first, they can't interfere with each other at all.
Basically if you have code which tries to rely on the order of simultaneous calls, you already have a race condition. Even if in the calling code one thread gets to the start of the next() call before the other, you can imagine it coming to the end of its time-slice before it gets into the next() call - allowing the second thread to get in there.
If the next() call had any other side effect - e.g. it printed out "Starting with thread (thread id)" and then returned the next value, then it wouldn't be atomic; you'd have an observable difference in behaviour. As it is, I think you're fine.
One thing to think about regarding wrapping: you can make the counter last an awful lot longer before wrapping if you use an AtomicLong :)
EDIT: I've just thought of a neat way of avoiding the wrapping problem in all realistic scenarios:
Define some large number M * 100000 (or whatever). This should be chosen to be large enough to not be hit too often (as it will reduce performance) but small enough that you can expect the "fixing" loop below to be effective before too many threads have added to the tick to cause it to wrap.
When you fetch the value with getAndIncrement(), check whether it's greater than this number. If it is, go into a "reduction loop" which would look something like this:
long tmp;
while ((tmp = tick.get()) > SAFETY_VALUE))
{
long newValue = tmp - SAFETY_VALUE;
tick.compareAndSet(tmp, newValue);
}
Basically this says, "We need to get the value back into a safe range, by decrementing some multiple of the modulus" (so that it doesn't change the value mod M). It does this in a tight loop, basically working out what the new value should be, but only making a change if nothing else has changed the value in between.
It could cause a problem in pathological conditions where you had an infinite number of threads trying to increment the value, but I think it would realistically be okay.
Concerning the atomicity problem: I don't believe that it's possible for the Counter itself to provide behaviour to guarantee the semantics you're implying.
I think we have a thread doing some work
A - get some stuff (for example receive a message)
B - prepare to call Counter
C - Enter Counter <=== counter code is now in control
D - Increment
E - return from Counter <==== just about to leave counter's control
F - application continues
The mediation you're looking for concerns the "payload" identity ordering established at A.
For example two threads each read a message - one reads X, one reads Y. You want to ensure that X gets the first counter increment, Y gets the second, even though the two threads are running simultaneously, and may be scheduled arbitarily across 1 or more CPUs.
Hence any ordering must be imposed across all the steps A-F, and enforced by some concurrency countrol outside of the Counter. For example:
pre-A - Get a lock on Counter (or other lock)
A - get some stuff (for example receive a message)
B - prepare to call Counter
C - Enter Counter <=== counter code is now in control
D - Increment
E - return from Counter <==== just about to leave counter's control
F - application continues
post- F - release lock
Now we have a guarantee at the expense of some parallelism; the threads are waiting for each other. When strict ordering is a requirement this does tend to limit concurrency; it's a common problem in messaging systems.
Concerning the List question. Thread-safety should be seen in terms of interface guarantees. There is absolute minimum requriement: the List must be resilient in the face of simultaneous access from several threads. For example, we could imagine an unsafe list that could deadlock or leave the list mis-linked so that any iteration would loop for ever. The next requirement is that we should specify behaviour when two threads access at the same time. There's lots of cases, here's a few
a). Two threads attempt to add
b). One thread adds item with key "X", another attempts to delete the item with key "X"
C). One thread is iterating while a second thread is adding
Providing that the implementation has clearly defined behaviour in each case it's thread-safe. The interesting question is what behaviours are convenient.
We can simply synchronise on the list, and hence easily give well-understood behaviour for a and b. However that comes at a cost in terms of parallelism. And I'm arguing that it had no value to do this, as you still need to synchronise at some higher level to get useful semantics. So I would have an interface spec saying "Adds happen in any order".
As for iteration - that's a hard problem, have a look at what the Java collections promise: not a lot!
This article , which discusses Java collections may be interesting.
Atomic (as I understand) refers to the fact that an intermediate state is not observable from outside. atomicInteger.incrementAndGet() is atomic, while return this.intField++; is not, in the sense that in the former, you can not observe a state in which the integer has been incremented, but has not yet being returned.
As for thread-safety, authors of Java Concurrency in Practice provide one definition in their book:
A class is thread-safe if it behaves
correctly when accessed from multiple
threads, regardless of the scheduling
or interleaving of the execution of
those threads by the runtime
environment, and with no additional
synchronization or other coordination
on the part of the calling code.
(My personal opinion follows)
Now, if we have the list
updated succesfully with two elements
added, but second comes before first,
which is at the end, is that "thread
safe"?
If thread1 entered the entry set of the mutex object (In case of Collections.synchronizedList() the list itself) before thread2, it is guaranteed that first is positioned ahead than second in the list after the update. This is because the synchronized keyword uses fair lock. Whoever sits ahead of the queue gets to do stuff first. Fair locks can be quite expensive and you can also have unfair locks in java (through the use of java.util.concurrent utilities). If you'd do that, then there is no such guarantee.
However, the java platform is not a real time computing platform, so you can't predict how long a piece of code requires to run. Which means, if you want first ahead of second, you need to ensure this explicitly in java. It is impossible to ensure this through "controlling the timing" of the call.
Now, what is thread safe or unsafe here? I think this simply depends on what needs to be done. If you just need to avoid the list being corrupted and it doesn't matter if first is first or second is first in the list, for the application to run correctly, then just avoiding the corruption is enough to establish thread-safety. If it doesn't, it is not.
So, I think thread-safety can not be defined in the absence of the particular functionality we are trying to achieve.
The famous String.hashCode() doesn't use any particular "synchronization mechanism" provided in java, but it is still thread safe because one can safely use it in their own app. without worrying about synchronization etc.
Famous String.hashCode() trick:
int hash = 0;
int hashCode(){
int hash = this.hash;
if(hash==0){
hash = this.hash = calcHash();
}
return hash;
}
Related
I got general understanding what volatile means in Java. But reading
Java SE Specification 8.3.1.4 I have a problem understanding the text beneath that certain volatile example.
class Test {
static volatile int i = 0, j = 0;
static void one() { i++; j++; }
static void two() {
System.out.println("i=" + i + " j=" + j);
}
}
This allows method one and method two to be executed concurrently, but
guarantees that accesses to the shared values for i and j occur
exactly as many times, and in exactly the same order, as they appear
to occur during execution of the program text by each thread.
Therefore, the shared value for j is never greater than that for i,
because each update to i must be reflected in the shared value for i
before the update to j occurs. It is possible, however, that any given
invocation of method two might observe a value for j that is much
greater than the value observed for i, because method one might be
executed many times between the moment when method two fetches the
value of i and the moment when method two fetches the value of j.
How is
j never greater than i
, but at the same time
any given invocation of method two might observe a value for j that is
much greater than the value observed for i
??
Looks like contradiction.
I got j greater than i after running sample program. Why use volatile then? It gives almost the same result without volatile (also i can be greater than j, one of previous examples in specs). Why is this example here as an alternative to synchronized?
At any one time, then j is not greater than i.
This is different from what method two observes because it is accessing the variables i and j at different times. i is accessed first, and then j is accessed slightly later.
This isn't a direct alternative to the synchronized version because the behavior is different. One difference from not using volatile is that without volatile, values of 0 could always be printed. The increment doesn't ever need to be visible.
The example demonstrates the ordering of volatile accesses. An example that requires this could be something like:
volatile boolean flag = false;
volatile int value;
// Thread 1
if(!flag) {
value = ...;
flag = true;
}
// Thread 2
if(flag) {
System.out.println(value);
flag = false;
}
and thread 2 reads the value that thread 1 set rather than an old value.
I'd like to propose that it's a mistake and the examples were supposed to print j before i:
static void two() {
System.out.println("j=" + j + " i=" + i);
}
The novelty in the first example is that, due to update reordering, j can be greater than i even when observed first.
The final example now makes perfect sense with some minor edits to the explanation (edits and commentary in brackets):
This allows method one and method two to be executed concurrently, but guarantees that accesses to the shared values for i and j occur exactly as many times, and in exactly the same order, as they appear to occur during execution of the program text by each thread. Therefore, the shared value for j is never [observed to be] greater than that for i, because each update to i must be reflected in the shared value for i before the update to j occurs. It is possible, however, that any given invocation of method two might observe a value for [i] that is much greater than the value observed for [j], because method one might be executed many times between the moment when method two fetches the value of [j] and the moment when method two fetches the value of [i].
The key point here is that the second update will never be observed before the first update, when using volatile. The last sentence about the gap between the two reads is entirely parenthetical, and i and j were swapped to conform to the erroneous example.
I think the point of the example is to emphasize that you need to take care and ensure the order when using volatile; the behavior may be counter-intuitive and the example demonstrates it.
I agree that the wording there is a bit obscure and it is possible to provide more explicit and clear example for multiple cases, but there is no contradiction.
The shared value is the value at the same moment. If two threads read values of i and of j at exactly the same moment, the value of j will never be observed greater than i. volatile guarantees keeping order of reads and updates as in the code.
However, in the sample, print + i and + j are two different operations separated by an arbitrary amount of time; hence, j can be observed larger than i, because it can be updated arbitrary number of times after the read of i and before the read of j.
The point of using volatile is that when you concurrently update and access volatile variables with the right order, you can make assumptions that are not possible in principle without volatile.
In the sample above, the order of access in two() does not allow to conclude with a confidence which variable is greater or equal.
Consider, however, if the sample was changed to System.out.println("j=" + j + " i=" + i);
Here you can assert with a confidence that the printed value of j is never larger than the printed value of i. This assumption will not hold without volatile for two reasons.
First, updates i++ and j++ can be executed by compiler and hardware in an arbitrary order and in reality may execute as j++;i++. If from other thread you then access j and i after j++ but before i++, you can observe, say, j=1 and i=0, regardless of the access order. volatile guarantees that this will not happen and it will execute operations in the order that is written in your source.
Second, volatile guarantees that another thread will see most recent values changed by another thread, as long as it accesses it in the later point of time after the last update. Without volatile, there can be no assumptions about the observed value. In theory, the value can stay for another thread zero forever. The program may print two zeros, zero and an arbitrary number, etc. from past updates; the observed value in other threads may be less than the current value that the updater thread sees after an update. volatile guarantees that you will see the value in a second thread after the update in the first.
While the second guarantee may seem as a consequence of the first (the order guarantee), they are in fact orthogonal.
Regarding synchronized, it allows to execute a sequence of non-atomic operations, like i++;j++ as an atomic operation, e.g. if one thread does synchronized i++;j++ and another does synchronized System.out.println("i=" + i + " j=" + j);, the first thread may not perform increment sequence while the second prints and the result will be correct.
But this comes at a cost. First, synhronized has a performance penalty by itself. Second, more important, not always such behavior is required and the blocked thread wastes time, reducing the system throughput (e.g. you can do so many i++;j++; during System.out).
How is j never greater than i?
Let's say you execute one() only once. During the execution of this method, i is always incremented before j as the increment operations happen one after the other.
If you are executing one() concurrently, each individual method call will wait for other methods in the execution queue to finish writing their values to i or j, depending on which variable the currently executing method is trying to increment. So, all writes to i happen one after the other, and all writes to j happen one after the other. And since within the method body itself i is incremented before j, at a given instant, j will never be greater than i.
any given invocation of method two might observe a value for j that is much greater than the value observed for i, how?
If method one() is being executed in the background while you call two(), between the time when i is read and then j is read, the method one can be executed multiple times. So, when the value of i is read it could be the result some invocation of one() that happened at time t=0, and when then value of j is read, it could be the result of an invocation of one() that happened later in time, for example at t=10. Hence, j can be greater than i in this case in the println statement.
Why use volatile in lieu of synchronized?
I will not list all the reasons why anyone should use volatile instead of a synchronized block. But bear in mind that volatile guarantees atomic access to that particular field alone, and does not ensure the atomic execution of a block of code that is not marked as synchronized. In this example, access to i and j are synchronized, but the overall operation {i++;j++} isn't synchronized hence it apparently (I use apparently since it is not exactly the same but looks similar) gives the same results as without using the volatile keyword.
How is
j never greater than i
, but at the same time
any given invocation of method two might observe a value for j that is much >>greater than the value observed for i
??
The first statement is always true at any given moment in the program's execution, and the second statement may be true for any given interval in the program's execution.
When a volatile variable is written to, writes to both it and everything before it must become visible to other threads (In Java 5+, at least. The explanation doesn't really change much for versions of Java before that, though). Thus, the increment of i must be visible by the time j is incremented, meaning that j can never appear greater than i to other threads.
The reads of i and j, though, are not guaranteed to occur at a single moment in the program execution. The read of i and j may appear to occur very close to each other to the thread executing two(), but in reality some arbitrary amount of time may have passed between the reads. For example, two() may read i when i = 5 and j = 5, but then get "frozen" while other threads execute, changing the values of i and j to, say, 20 and 19, respectively. When two() resumes, it picks up where it left off and reads j, which now has a value of 19. two() doesn't re-read i because as far as it is concerned there was no break in execution, so there is no need to undergo the extra work.
Why use volatile then?
While both volatile and synchronized provide visibility guarantees, the precise semantics are slightly different. volatile guarantees that changes made to the variable will be instantly visible to all threads, while synchronized guarantees that changes made in its block will be visible to all threads as long as they synchronize on the same lock. synchronized also provides additional atomicity guarantees that volatile does not.
Why is this example here as an alternative to synchronized?
volatile is a viable alternative to synchronized only if one() is executed by a single thread, which is the case here. In this case, only a single thread is ever writing to i and j, so there is no need for the atomicity guarantees synchronized provides. If one() were executed by multiple threads, volatile wouldn't work because the read-add-store operations that make up an increment must occur atomically, and volatile does not guarantee that.
This program does guarantee that method two() observes j >= i-1 (not considering overflow).
Without volatile, the observed values of i,j could be all over the place.
The statement
the shared value for j is never greater than that for i
is very informal, because it means "at the same time", which is not a defined concept in JMM.
The core principle of JMM is about "sequential consistency". The driving motivation of JMM is
JLS#17 - If a program is correctly synchronized, then all executions of the program will appear to be sequentially consistent
In the following program
void f()
{
int x=0, y=0;
x++;
print( x>y );
y++
}
x>y will always be observed as true. It has to be, if we follow the sequence of actions. Otherwise, there is really no way for us to reason about any (imperative) code. That is "sequential consistency".
"Sequential consistency" is an observed property, it doesn't have to coincide with "real" actions (whatever that means). It is entirely possible that x>y is evaluated to be true by JVM before x is actually incremented (or at all). As long as JVM can guarantee observed sequential consistency, it can optimize actual execution anyway it can, e.g. execute code out of order.
But this is for a singlet thread. If multiple threads are reading/writing shared variables, such optimizations of course will completely wreck sequential consistency. We cannot reason about program behavior by thinking of interleaving actions from multiple threads (with actions in the same thread following intra-thread sequence).
If we want to guarantee inter-thread sequential consistency of any multi-thread code, we must abandon the optimization techniques developed for single thread. That is going to have severe performance penalty for most programs. And it is also uncalled for -- data exchange among threads is rather rare.
Therefore, special instructions are created just for establishing inter-thread sequential consistency when it is needed. Volatile reads and writes are such actions. All volatile reads and writes obey inter-thread sequential consistency. In this case, it guarantees that j >= i-1 in two().
All dependes on how you are using it. The volatile keyword in Java is used as an indicator to Java compiler and Thread that do not cache value of this variable and always read it from main memory. So if you want to share any variable in which read and write operation is atomic by implementation e.g. read and write in an int or a boolean variable then you can declare them as volatile variable.
From Java 5 along with major changes like Autoboxing, Enum, Generics and Variable arguments , Java introduces some change in Java Memory Model (JMM), Which guarantees visibility of changes made from one thread to another also as "happens-before" which solves the problem of memory writes that happen in one thread can "leak through" and be seen by another thread.
The Java volatile keyword cannot be used with method or class and it can only be used with a variable. Java volatile keyword also guarantees visibility and ordering, after Java 5 write to any volatile variable happens before any read into the volatile variable. By the way use of volatile keyword also prevents compiler or JVM from the reordering of code or moving away them from synchronization barrier.
Important points on Volatile keyword in Java
The volatile keyword in Java is only application to a variable and using volatile keyword with class and method is illegal.
volatile keyword in Java guarantees that value of the volatile variable will always be read from main memory and not from Thread's local cache.
In Java reads and writes are atomic for all variables declared using Java volatile keyword (including long and double variables).
Using the volatile keyword in Java on variables reduces the risk of memory consistency errors because any write to a volatile variable in Java establishes a happens-before relationship with subsequent reads of that same variable.
I do understand that it is better to use AtomicInteger instead of synchronized block to increment a shared int value. However, would it still hold in case of multiple int values?
Which one of the below methods would be better and why? Is there a better way to do it to improve performance?
1) Using synchronized block:
int i, j, k, l;
public void synchronized incrementValues() {
i++;j++;k++;l++;
}
2) Using AtomicInteger:
AtomicInteger i,j,k,l;
// Initialize i, j, k, l
public void incrementValues() {
i.incrementAndGet();
j.incrementAndGet();
k.incrementAndGet();
l.incrementAndGet();
}
Or would it be faster if I use ReentrantLock?
3) Using ReentrantLock :
ReentrantLock lock = new ReentrantLock()
int i, j, k, l;
public void incrementValues() {
lock.lock();
try {
i++;j++;k++;l++;
} finally {
lock.unlock();
}
}
Here are my questions:
Is 3 the fastest of them all?
What about 2? For single integer 2 is faster than 1. Will 2 become slower than 1 if the number of integers increase?
Edit 1
Modified question Based on Matthias answer.
i,j,k,l are independent of each other. Individual increments should be atomic, not the whole. It is ok if thread 2 modifies i before thread 1 modifies k.
Edit 2
Additional Info based on comments so far
I am not looking for an exact answer, as I understand that it would depend on how the functions are used and the amount of contention etc. and measuring for each of the use cases is the best way to determine the exact answer. However, I would like to see people share their knowledge/articles etc. that would throw light on the parameters/optimizations affecting the situation. Thanks for the article #Marco13. It was informative.
First of all, #2 is not thread safe. incrementAndGet() is atomic, however, calling four incrementAndGet operations in a row is not. (e.g. after the second incrementAndGet, another thread could get into the same method and start doing the same like in the example below.
T1: i.incrementAndGet();
T1: j.incrementAndGet();
T1: k.incrementAndGet();
T2: i.incrementAndGet();
T2: j.incrementAndGet();
T1: l.incrementAndGet();
T2: k.incrementAndGet();
T2: l.incrementAndGet();
then, if it is between #1 and #3: If you're not into high speed stock trading, it won't matter for you. There might be really small differences (in the case of just integers probably in nanoseconds), but it won't really matter. However, I would always go for #1, as it's much simpler and also much safer to use (e.g. imagine you would have forgotten to put the unlock() in the finally block - then you could get into big trouble)
Regarding your edits:
For number 1: sometimes it could be important to atomically modify several values at once. Consider that data is not only incremented but also read at the same time. You would assume that at any point in time all variables very the same value. However as the update operation is not atomic when you read the data, it could be that I=j=k=5 and l=4 because the thread that did the increment has not yet arrived at the last operation.
Whether this is a problem depends very much on your problem. If you don't need such a guarantee, don't care.
For number 2:
Optimisation is hard and concurrency is even harder. I can only recommend NOT thinking about such micro oprimizations. In the best case these optimizations save nanoseconds but make the code very complex. In the worst case there's a false assumption or logical error in the optimisation and you will end up with concurrency problems. Most likely however your optimization will perform worse.
Also consider that the code you write will probalbly need to be maintained by someone else at a later point in time. And where you saved milliseconds in programming execution you waste hours of you processors life who is trying to understand what you want to do and why you do it this way while attempting to fix that nasty multi threading bug.
So for the sake of ease: synchronized is the best thing to use.
The kiss principle REALLY holds true for concurrency.
Quick question? Is this line atomic in C++ and Java?
class foo {
bool test() {
// Is this line atomic?
return a==1 ? 1 : 0;
}
int a;
}
If there are multiple thread accessing that line, we could end up with doing the check
a==1 first, then a is updated, then return, right?
Added: I didn't complete the class and of course, there are other parts which update a...
No, for both C++ and Java.
In Java, you need to make your method synchronized and protect other uses of a in the same way. Make sure you're synchronizing on the same object in all cases.
In C++, you need to use std::mutex to protect a, probably using std::lock_guard to make sure you properly unlock the mutex at the end of your function.
return a==1 ? 1 : 0;
is a simple way of writing
if(a == 1)
return 1;
else
return 0;
I don't see any code for updating a. But I think you could figure it out.
Regardless of whether there is a write, reading the value of a non-atomic type in C++ is not an atomic operation. If there are no writes then you might not care whether it's atomic; if some other thread might be modifying the value then you certainly do care.
The correct way of putting it is simply: No! (both for Java and C++)
A less correct, but more practical answer is: Technically this is not atomic, but on most mainstream architectures, it is at least for C++.
Nothing is being modified in the code you posted, the variable is only tested. The code will thus usually result in a single TEST (or similar) instruction accessing that memory location, and that is, incidentially, atomic. The instruction will read a cache line, and there will be one well-defined value in the respective loaction, whatever it may be.
However, this is incidential/accidential, not something you can rely on.
It will usually even work -- again, incidentially/accidentially -- when a single other thread writes to the value. For this, the CPU fetches a cache line, overwrites the location for the respective address within the cache line, and writes back the entire cache line to RAM. When you test the variable, you fetch a cache line which contains either the old or the new value (nothing in between). No happens-before guarantees of any kind, but you can still consider this "atomic".
It is much more complicated when several threads modify that variable concurrently (not part of the question). For this to work properly, you need to use something from C++11 <atomic>, or use an atomic intrinsic, or something similar. Otherwise it is very much unclear what happens, and what the result of an operation may be -- one thread might read the value, increment it and write it back, but another one might read the original value before the modified value is written back.
This is more or less guaranteed to end badly, on all current platforms.
No, it is not atomic (in general) although it can be in some architectures (in C++, for example, in intel if the integer is aligned which it will be unless you force it not to be).
Consider these three threads:
// thread one: // thread two: //thread three
while (true) while (true) while (a) ;
a = 0xFFFF0000; a = 0x0000FFFF;
If the write to a is not atomic (for example, intel if a is unaligned, and for the sake of discussion with 16bits in each one of two consecutive cache lines). Now while it seems that the third thread cannot ever come out of the loop (the two possible values of a are both non-zero), the fact is that the assignments are not atomic, thread two could update the higher 16bits to be 0, and thread three could read the lower 16bits to be 0 before thread two gets the time to complete the update, and come out of the loop.
The whole conditional is irrelevant to the question, since the returned value is local to the thread.
No, it still a test followed by a set and then a return.
Yes, multithreadedness will be a problem.
It's just syntactic sugar.
Your question can be rephrased as: is statement:
a == 1
atomic or not? No it is not atomic, you should use std::atomic for a or check that condition under lock of some sort. If whole ternary operator atomic or not does not matter in this context as it does not change anything. If you mean in your question if in this code:
bool flag = somefoo.test();
flag to be consistent to a == 1, it would definitely not, and it irrelevant if whole ternary operator in your question is atomic.
There a lot of good answers here, but none of them mention the need in Java to mark a as volatile.
This is especially important if no other synchronization method is employed, but other threads could updating a. Otherwise, you could be reading an old value of a.
Consider the following code:
bool done = false;
void Thread1() {
while (!done) {
do_something_useful_in_a_loop_1();
}
do_thread1_cleanup();
}
void Thread2() {
do_something_useful_2();
done = true;
do_thread2_cleanup();
}
The synchronization between these two threads is done using a boolean variable done. This is a wrong way to synchronize two threads.
On x86, the biggest issue is the compile-time optimizations.
Part of the code of do_something_useful_2() can be moved below "done = true" by the compiler.
Part of the code of do_thread2_cleanup() can be moved above "done = true" by the compiler.
If do_something_useful_in_a_loop_1() doesn't modify "done", the compiler may re-write Thread1 in the following way:
if (!done) {
while(true) {
do_something_useful_in_a_loop_1();
}
}
do_thread1_cleanup();
so Thread1 will never exit.
On architectures other than x86, the cache effects or out-of-order instruction execution may lead to other subtle problems.
Most race detector will detect such race.
Also, most dynamic race detectors will report data races on the memory accesses that were intended to be synchronized with this bool
(i.e. between do_something_useful_2() and do_thread1_cleanup())
To fix such race you need to use compiler and/or memory barriers (if you are not an expert -- simply use locks).
I'm study java.util.concurrent library and find many infinite loops in the source code, like this one
//java.util.concurrent.atomic.AtomicInteger by Doug Lea
public final int getAndSet(int newValue) {
for (;;) {
int current = get();
if (compareAndSet(current, newValue))
return current;
}
}
I wonder, in what cases actual value can not be equal to the expected value (in this case compareAndSet returns false)?
Many modern CPUs have compareAndSet() map to an atomic hardware operation. That means, it is threadsafe without requiring synchronization (which is a relatively expensive operation in comparison). However, it's only compareAndSet() itself with is atomic, so in order to getAndSet() (i.e. set the variable to a given value and return the value it had at that time, without the possibility of it being set to a different value in between) the code uses a trick: first it gets the value, then it attempts compareAndSet() with the value it just got and the new value. If that fails, the variable was manipulated by another thread inbetween, and the code tries again.
This is faster than using synchronization if compareAndSet() fails rarely, i.e. if there are not too many threads writing to the variable at the same time. In an extreme case where many threads are writing to the variable at all times, synchronization can actually be faster because while there is an overhead to synchronize, other threads trying to access the variable will wait and be woken up when it's their turn, rather than having to retry the operation repeatedly.
When the value is modified in another thread, the get() and compareAndSet() can see different values. This is the sort of thing a concurrent library needs to worry about.
This is not an infinite loop, it is good practice when dealing with a TAS (test and set) algorithm. What the loop does is (a) read from memory (should be volatile semantics) (b) compute a new value (c) write the new value if the old value has not in the meantime changed.
In database land this is known as optimistic locking. It leverages the fact that most concurrent updates to shared memory are uncontended, and in that case, this is the cheapest possible way to do it.
In fact, this is basically what an unbiased Lock will do in the uncontended case. It will read the value of the lock, and if it is unlocked, it will do a CAS of the thread ID and if that succeeds, the lock is now held. If it fails, someone else got the lock first. Locks though deal with the failure case in a much more sophisticated way than merely retrying the op over and over again. They'll keep reading it for a little while incase the lock is quickly unlocked (spin-locking) then usually go to sleep for bit to let other threads in until their turn (exponential back-off).
Here is an actual usage of the compareAndSet operation: Imagine that you design an algorithm that calculates something in multiple threads.
Each thread remembers an old value and based on it performs a complicated calculation.
Then it wants to set the new result ONLY if the old value hasn't been already changed by another calculation thread. If the old value is not the expected one the thread discards its own work, takes a new value and restarts the calculations. It uses compareAndSet for that.
Further other threads are guaranteed to get only fresh values to continue the calculations.
The "infinite" loops are used to implement "busy waiting" which might be much less expensive than putting the thread to sleep especially when the thread contention is low.
Cheers!
Lets say I'm interacting with a system that has two incrementing counters which depend on each other (these counters will never decrement):
int totalFoos; // barredFoos plus nonBarredFoos
int barredFoos;
I also have two methods:
int getTotalFoos(); // Basically a network call to localhost
int getBarredFoos(); // Basically a network call to localhost
These two counters are kept and incremented by code that I don't have access to. Let's assume that it increments both counters on an alternate thread but in a thread-safe manner (i.e. at any given point in time the two counters will be in sync).
What is the best way to get an accurate count of both barredFoos and nonBarredFoos at a single point in time?
The completely naive implementation:
int totalFoos = getTotalFoos();
int barredFoos = getBarredFoos();
int nonBarredFoos = totalFoos - barredFoos;
This has the issue that the system could increment both counters in between the two method calls and then my two copies would be out of sync and barredFoos would have a value of more than it did when totalFoos was fetched.
Basic double-checked implementation:
while (true) {
int totalFoos = getTotalFoos();
int barredFoos = getBarredFoos();
if (totalFoos == getTotalFoos()) {
// totalFoos did not change during fetch of barredFoos, so barredFoos should be accurate.
int nonBarredFoos = totalFoos - barredFoos;
break;
}
// totalFoos changed during fetch of barredFoos, try again
}
This should work in theory, but I'm not sure that the JVM guarantees that this is what actually happens in practice once optimization and such is taken into account. For an example of these concerns, see http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html (Link via Romain Muller).
Given the methods I have and the assumption above that the counters are in fact updated together, is there a way I can guarantee that my copies of the two counts are in sync?
Yes, I believe your implementation will be sufficient; the real work is making sure that the values that are returned by getTotalFoos and getBarredFoos are indeed synchronized and always returning the latest values. However, as you've said, this is already the case.
Of course, one thing you could run in to with this code is an endless loop; you would want to be sure that the two values being changed in such a short time would be a very exceptional situation, and even then I think that it would definitely be wise to build in a safety (ie maximum number of iterations) to avoid getting into an endless loop. If the value coming out of those counter is in code that you don't have access to, you don't want to be totally relying on the fact that things will never go awry at the other end.
To guarantee read consitency across threads - and prevent code execution re-ordering, especially on muli-core machines, you need to synchronize all read and write access to those variables. In addition, to ensure that on a single thread you see the most up to date values of all variables being used in the current computation you need to synchronise on read access.
Update: I missed the bit about the calls to get the values of both variables being separate calls over the network - which renders this the double-checked locking problem (so without an api method available to you that returns both values at once you cann't absolutely guarantee consistency of both variables at any point in time).
See Brian Goetz's article on Java memory model.
You can probably not reliably do what you want unless the system you are interacting with has a method that enables you to retrieve both values at once (in an atomic way).
I was going to mention AtomicInteger as well, but that won't work, because
1) you've got TWO integers, not just one. AtomicIntegers won't help you.
2) He doesn't have access to the underlying code.
My question is, even if you can't modify the underlying code, can you control when it's executed? You could put synchronization blocks around any functions that modify those counters. That might not be pleasant, (it could be slower then your loop) but that would arguably be the 'correct' way to do it.
If you can't even control the internal threads, then I guess your loop would work.
And finally, if you ever do get control of the code, the best thing would be to have one synchronized function that blocks access to both integers as it runs, and returns the two of them in an int[].
Given that there's no way to access whatever locking mechanism is maintaining the invariant "totalFoos = barredFoos + nonBarredFoos", there's no way to ensure that the values you retrieve are consistent with that invariant. Sorry.
The method that contains the code
while (true) {
int totalFoos = getTotalFoos();
int barredFoos = getBarredFoos();
if (totalFoos == getTotalFoos()) {
int nonBarredFoos = totalFoos - barredFoos;
break;
}
}
Should be synchronized
private synchronized void getFoos()