I found a solution to the mutual-exclusion problem online that has two processes P0 and P1. (Assume that the variable turn is initialized to 0)
volatile int turn;
Process P0:
/* Other code */
while (turn != 0) { } /* Do nothing and wait. */
Critical Section /* . . . */
turn = 1;
/* Other code */
Process P1:
/*Other code*/
while (turn != 1) { } /* Do nothing and wait. */
Critical Section /* . . . */
turn = 0;
/* Other code */
How does this solution solve the mutual-exclusion problem? I don't understand it fully.
Assuming there's no other code that can set turn to a value other than 0 or 1, and assuming the only thing messing with the turn variable are P0 and P1, then this does solve the mutual exclusion property. Specifically, you say that turn is initialized to 0. So that means P1 can't enter the critical section: it's busy in the while (turn != 1) loop and it'll stay in that loop until something sets turn == 1. Given our assumption that only P0 and P1 make changes to turn that means P1 can't enter the critical section until P0 sets turn to 1. So P0 will immediately exit it's while (turn != 0) loop (as turn is initially 0) and safely enter its critical section. It knows P1 can't enter it's critical section until turn gets set to 1 and that only happens after P0 has left it's critical section. Once P0 sets turn to 1, P0 will be stuck in it's while (turn != 0) loop until P1 sets it free so now P1 is in it's critical section and P0 can't be in it's. And so on.
An easy way to think of this is two people and a batton. They each agree not to do anything (enter their critical section) unless they hold the batton. So Person 1 has the batton at first and is free to do stuff knowing that Person 2 can't do anything - they don't have the batton. Once Person 1 is done, they hand the batton to Person 2. Person 2 is now free to do whatever they want and they know Person 1 is doing nothing but waiting for the batton to be handed back to them.
As #JustinSteele points out, this definitely does not solve the mutual exclusion problem. Maybe if you would change the turn to a boolean, you could get a dirty fix, since a boolean only consists out of two values. If you want a more proper way of providing mutual exclusive, I would suggest to take a look at mutexes, semaphores and condition variables. Good luck!
If both P0 and P1 are executed, and each is executed only once, it is true that P0 will enter the critical section first, exclusively, before P1 does.
In term of Java Memory Model, this program is correctly synchronized, because all inter-thread actions are volatile reads and writes. Therefore the program is sequentially consistent, easy to analyze.
Or, more specifically, all volatile reads and writes are in a total order (that's consistent with the programming order); this order will guarantee the mutual exclusiveness of critical sections.
However, there is a serious problem here. If P1 arrives first, it must wait for P0, no matter how late P0 arrives. This is quite unfair. And, if P0 is not executed, P1 cannot advance. And, If P0 is executed and P1 is not, P0 cannot enter the critical section again (it must wait for P1 to reset the turn). This locking mechanism only allows a strict P0-P1-P0-P1-... sequence (unless that is exactly what's desired)
To solve this problem, there are Dekker's algorithm, Peterson's algorithm, etc. See this post - https://cs.stackexchange.com/a/12632
Related
This question already has answers here:
Reordering of reads
(2 answers)
Closed 2 years ago.
Consider this example. We're having:
int var = 0;
Thread A:
System.out.println(var);
System.out.println(var);
Thread B:
var = 1;
The threads run concurrently. Is the following output possible?
1
0
That is, the original value is read after the new value was read. The var isn't volatile. My gut feeling is that it's not possible.
You are using System.out.println that internally does a synchronized(this) {...} that will make things a bit more worse. But even with that, your reader thread can still observe 1, 0, i.e. : a racy read.
I am by far not an expert of this, but after going through lots of videos/examples/blogs from Alexey Shipilev, I think I understand at least something.
JLS states that :
If x and y are actions of the same thread and x comes before y in program order, then hb(x, y).
Since both reads of var are in program order, we can draw:
(po)
firstRead(var) ------> secondRead(var)
// po == program order
That sentence also says that this builds a happens-before order, so:
(hb)
firstRead(var) ------> secondRead(var)
// hb == happens before
But that is within "the same thread". If we want to reason about multiple threads, we need to look into synchronization order. We need that because the same paragraph about happens-before order says:
If an action x synchronizes-with a following action y, then we also have hb(x, y).
So if we build this chain of actions between program order and synchronizes-with order, we can reason about the result. Let's apply that to your code:
(NO SW) (hb)
write(var) ---------> firstRead(var) -------> secondRead(var)
// NO SW == there is "no synchronizes-with order" here
// hb == happens-before
And this is where happens-before consistency comes at play in the same chapter:
A set of actions A is happens-before consistent if for all reads r in A, where W(r) is the write action seen by r, it is not the case that either hb(r, W(r)) or that there exists a write w in A such that w.v = r.v and hb(W(r), w) and hb(w, r).
In a happens-before consistent set of actions, each read sees a write that it is allowed to see by the happens-before ordering
I admit that I very vaguely understand the first sentence and this is where Alexey has helped me the most, as he puts it:
Reads either see the last write that happened in the happens-before or any other write.
Because there is no synchronizes-with order there, and implicitly there is no happens-before order, the reading thread is allowed to read via a race.
and thus get 1, than 0.
As soon as you introduce a correct synchronizes-with order, for example one from here
An unlock action on monitor m synchronizes-with all subsequent lock actions on...
A write to a volatile variable v synchronizes-with all subsequent reads of v by any thread...
The graph changes (let's say you chose to make var volatile):
SW PO
write(var) ---------> firstRead(var) -------> secondRead(var)
// SW == there IS "synchronizes-with order" here
// PO == happens-before
PO (program order) gives that HB (happens before) via the first sentence I quoted in this answer from the JLS. And SW gives HB because:
If an action x synchronizes-with a following action y, then we also have hb(x, y).
As such:
HB HB
write(var) ---------> firstRead(var) -------> secondRead(var)
And now happens-before order says that the reading thread will read the value that was "written in the last HB", or it means that reading 1 then 0 is impossible.
I took the example jcstress samples and introduced a small change (just like your System.out.println does):
#JCStressTest
#Outcome(id = "0, 0", expect = Expect.ACCEPTABLE, desc = "Doing both reads early.")
#Outcome(id = "1, 1", expect = Expect.ACCEPTABLE, desc = "Doing both reads late.")
#Outcome(id = "0, 1", expect = Expect.ACCEPTABLE, desc = "Doing first read early, not surprising.")
#Outcome(id = "1, 0", expect = Expect.ACCEPTABLE_INTERESTING, desc = "First read seen racy value early, and the second one did not.")
#State
public class SO64983578 {
private final Holder h1 = new Holder();
private final Holder h2 = h1;
private static class Holder {
int a;
int trap;
}
#Actor
public void actor1() {
h1.a = 1;
}
#Actor
public void actor2(II_Result r) {
Holder h1 = this.h1;
Holder h2 = this.h2;
h1.trap = 0;
h2.trap = 0;
synchronized (this) {
r.r1 = h1.a;
}
synchronized (this) {
r.r2 = h2.a;
}
}
}
Notice the synchronized(this){....} that is not part of the initial example. Even with synchronization, I still can see that 1, 0 as a result. This is just to prove that even with synchronized (that comes internally from System.out.println), you can still get 1 than 0.
When the value of var is read and it's 1 it won't change back. This output can't happen, neither due to visibility nor reorderings. What can happen is 0 0, 0 1 and 1 1.
The key point to understand here is that println involves synchronization. Look inside that method and you should see a synchronized there. These blocks have the effect that the prints will happen in just that order. While the write can happen anywhen, it's not possible that the first print sees the new value of var but the second print sees the old value. Therefore, the write can only happen before both prints, in-between or after them.
Besides that, there is no guarantee that the write will be visible at all, as var is not marked with volatile nor is the write synchronized in any way.
I think what is missing here is the fact that those threads run on actual physical cores and we have few possible variants here:
all threads run on the same core, then the problem is reduced to the order of execution of those 3 instructions, in this case 1,0 is not possible I think, println executions are ordered due to the memory barriers created by synchronisation, so that excludes 1,0
A and B runs on 2 different cores, then 1,0 does not look possible either, as as soon the core that runs thread A reads 1, there is no way it will read 0 after, same as above printlns are ordered.
Thread A is rescheduled in between those 2 printlns, so the second println is executed on a different core, either the same as B was/will be executed or on a different 3rd core. So when the 2 printlns are executed on a different cores, it depends what value does 2 cores see, if var is not synchronised (it is not clear is var a member of this), then those 2 cores can see different var value, so there is a possibility for 1,0.
So this is a cache coherence problem.
P.S. I'm not a jvm expert, so there might be other things in play here.
Adding to the other answers:
With long and double, writes may not be atomic so the first 32 bits could become visible before the last 32 bits, or viceversa. Therefore completely different values could be output.
I've stumbled upon a modified version of the Bakerys Algorithm (an uncomplete one of course with flaws)
I've been asked in class if the following algorithm is can have a starvation issue:
while(true){
number[me] = max(number[0],...,number[n]) + 1
for (other from 0 to n) {
while(number[other] != 0 && number[other] < number[me]) {
// Wait
}
}
/*CS*/
number[me] = 0
}
I understand that a deadlock is possible however, I'm asking is this algorithm starvation-free ?
I think that it is, because I can guarantee that once thread A has chosen a number, other threads will always have a bigger number than thread A and therefor he will eventually be allowed to enter the CS
My friend thinks that the algorithm is not starvation free, since a thread can be stuck in the process of taking a number (calculating the max) and possibly get its CPU time taken from him. Meanwhile other threads will start & finish and perhaps start again (since the while true) while supposedly thread A is being starved.
My question can be simplified to this:
Does the choosing array in the original Bakerys Algorithm solve starvation ?
Starvation-freedom can be defined as: Any process trying to enter critical section, will eventually enter critical section.
The line that calculates max is not part of the critical section, so it will eventually receive cpu time to make that assignment.
When a process A receives its id, then it will wait for all the other process that has an id lower than the one it has (lower id means that has more priority). Sometime that processes will leave the critical section and will get a new id. This id will be greater than the one it has and in that moment process A will enter in the critical section.
Finally, the algorithm is starvation-free.
Going through the JLS by James Gosling, I came across this-
The Java programming language provides a second mechanism (other than synchronisation), volatile fields, that is more convenient than locking for some purposes.
A field may be declared volatile, in which case the Java Memory Model ensures that all threads see a consistent value for the variable.Then the author points to this resource.
It may appear that the result r2 == 2 and r1 == 1 is impossible.
But why?
Isn't it makes perfect sense to think of something like this-
Instruction 4 : A = 2;
Instruction 1 : r2 = A;
Instruction 2 : B = 1;
Instruction 3 : r1 = B;
And the rest I couldn't understand it either.
It may appear that the result r2 == 2 and r1 == 1 is impossible.
Intuitively, either instruction 1 or instruction 3 should come first
in an execution. If instruction 1 comes first, it should not be able
to see the write at instruction 4. If instruction 3 comes first, it
should not be able to see the write at instruction 2.
If some execution exhibited this behavior, then we would know that
instruction 4 came before instruction 1, which came before instruction
2, which came before instruction 3, which came before instruction 4.
This is, on the face of it, absurd.
However, compilers are allowed to reorder the instructions in either
thread, when this does not affect the execution of that thread in
isolation. If instruction 1 is reordered with instruction 2, as shown
in the trace in Table 17.4-B, then it is easy to see how the result r2
== 2 and r1 == 1 might occur.
Please exemplify.
This is a common rhetorical pattern in English writing. A writer says that something "may appear" to be the case or say that someone "might think" something is the case, they explain the invalid reasoning that might lead to that conclusion, and then they go on to explain how it's not in fact the case. Using this rhetorical technique, the middle section consists of statements that are known by the writer to be incorrect.
The section you are quoting is intended to explain precisely what it is that you already understand -- compilers are generally free to reorder memory reads and writes if they can't affect single-threaded code.
So for example, in this paragraph:
It may appear that the result r2 == 2 and r1 == 1 is impossible. Intuitively, either instruction 1 or instruction 3 should come first in an execution. If instruction 1 comes first, it should not be able to see the write at instruction 4. If instruction 3 comes first, it should not be able to see the write at instruction 2.
By "may appear" he means that someone might think it, but it's not true. He then goes on to explain why someone might think it and then explain why that would be wrong. The sentences after the first one in that paragraph are known to be wrong by the writer, and he will then go on to explain how they are wrong.
I've been reading about non-blocking approaches for some time. Here is a piece of code for so called lock-free counter.
public class CasCounter {
private SimulatedCAS value;
public int getValue() {
return value.get();
}
public int increment() {
int v;
do {
v = value.get();
}
while (v != value.compareAndSwap(v, v + 1));
return v + 1;
}
}
I was just wondering about this loop:
do {
v = value.get();
}
while (v != value.compareAndSwap(v, v + 1));
People say:
So it tries again, and again, until all other threads trying to change the value have done so. This is lock free as no lock is used, but not blocking free as it may have to try again (which is rare) more than once (very rare).
My question is:
How can they be so sure about that? As for me I can't see any reason why this loop can't be infinite, unless JVM has some special mechanisms to solve this.
The loop can be infinite (since it can generate starvation for your thread), but the likelihood for that happening is very small. In order for you to get starvation you need some other thread succeeding in changing the value that you want to update between your read and your store and for that to happen repeatedly.
It would be possible to write code to trigger starvation but for real programs it would be unlikely to happen.
The compare and swap is usually used when you don't think you will have write conflicts very often. Say there is a 50% chance of "miss" when you update, then there is a 25% chance that you will miss in two loops and less than 0.1% chance that no update would succeed in 10 loops. For real world examples, a 50% miss rate is very high (basically not doing anything than updating), and as the miss rate is reduces, to say 1% then the risk of not succeeding in two tries is only 0.01% and in 3 tries 0.0001%.
The usage is similar to the following problem
Set a variable a to 0 and have two threads updating it with a = a+1 a million times each concurrently. At the end a could have any answer between 1000000 (every other update was lost due to overwrite) and 2000000 (no update was overwritten).
The closer to 2000000 you get the more likely the CAS usage is to work since that mean that quite often the CAS would see the expected value and be able to set with the new value.
Edit: I think I have a satisfactory answer now. The bit that confused me was the 'v != compareAndSwap'. In the actual code, CAS returns true if the value is equal to the compared expression. Thus, even if the first thread is interrupted between get and CAS, the second thread will succeed the swap and exit the method, so the first thread will be able to do the CAS.
Of course, it is possible that if two threads call this method an infinite number of times, one of them will not get the chance to run the CAS at all, especially if it has a lower priority, but this is one of the risks of unfair locking (the probability is very low however). As I've said, a queue mechanism would be able to solve this problem.
Sorry for the initial wrong assumptions.
First of all: this is not a homework assignment, it's for a hobby project of mine.
Background:
For my Java puzzle game I use a very simple recursive algorithm to check if certain spaces on the 'map' have become isolated after a piece is placed. Isolated in this case means: where no pieces can be placed in.
Current Algorithm:
public int isolatedSpace(Tile currentTile, int currentSpace){
if(currentTile != null){
if(currentTile.isOpen()){
currentTile.flag(); // mark as visited
currentSpace += 1;
currentSpace = isolatedSpace(currentTile.rightNeighbor(),currentSpace);
currentSpace = isolatedSpace(currentTile.underNeighbor(),currentSpace);
currentSpace = isolatedSpace(currentTile.leftNeighbor(),currentSpace);
currentSpace = isolatedSpace(currentTile.upperNeighbor(),currentSpace);
if(currentSpace < 3){currentTile.markAsIsolated();} // <-- the problem
}
}
return currentSpace;
}
This piece of code returns the size of the empty space where the starting tile is part of. That part of the code works as intented. But I came across a problem regarding the marking of the tiles and that is what makes the title of this question relevant ;)
The problem:
The problem is that certain tiles are never 'revisited' (they return a value and terminate, so never get a return value themselves from a later incarnation to update the size of the empty space). These 'forgotten' tiles can be part of a large space but still marked as isolated because they were visited at the beginning of the process when currentSpace had a low value.
Question:
How to improve this code so it sets the correct value to the tiles without too much overhead? I can think of ugly solutions like revisiting all flagged tiles and if they have the proper value check if the neighbors have the same value, if not update etc. But I'm sure there are brilliant people here on Stack Overflow with much better ideas ;)
Update:
I've made some changes.
public int isolatedSpace(Tile currentTile, int currentSpace, LinkedList<Tile> visitedTiles){
if(currentTile != null){
if(currentTile.isOpen()){
// do the same as before
visitedTiles.add();
}
}
return currentSpace;
}
And the marktiles function (only called when the returned spacesize is smaller than a given value)
marktiles(visitedTiles){
for(Tile t : visitedTiles){
t.markAsIsolated();
}
}
This approach is in line with the answer of Rex Kerr, at least if I understood his idea.
This isn't a general solution, but you only mark spaces as isolated if they occur in a region of two or fewer spaces. Can't you simplify this test to "a space is isolated iff either (a) it has no open neighbours or (b) precisely one open neighbour and that neighbour has no other open neighbours".
You need to have a two-step process: gathering info about whether a space is isolated, and then then marking as isolated separately. So you'll need to first count up all the spaces (using one recursive function) and then mark all connected spaces if the criterion passes (using a different recursive function).