Multithreading, Synchronization and ArrayLists

[Jake Jameson]

I need to add words to a static field infiList with type ArrayList<String>

public static ArrayList<String> infiList;

With the use of threading

Each of these three threads should perform the same task (simultaneously with the other threads):
each thread should repeatedly add words to infiList (using an infinite loop), according to the following rules:

1) In each loop pass, the thread should add exactly one word to infiList.
2) If the last word in infiList is currently “This”, the thread should append word “is” to infiList.
3) If the last word in infiList is currently “is”, the thread should append word “infinite” to infiList.
4) If the last word in infiList is currently “infinite”, or if infiList is still empty, the thread should
append word “This” to infiList.
5) At any time, infiList should contain “This” only at the beginning of the list or directly after an
occurrence of “infinite”, “is” should occur in the list only directly after a “This”, and an “infinite” should
occur only directly after an “is”. No other words are allowed in infiList.

Example: after a while, infiList should contain the following list of strings: “This”, “is”, “infinite”, “This”, “is”,
“infinite”, “This”, “is”, “infinite”, “This”, “is”, “infinite”, “This”, “is”, ...

I'm new to all this but here is my attempt so far which is probably all wrong

import java.util.ArrayList;


import java.util.List;
import java.lang.reflect.Type;
import java.lang.reflect.Field;
import java.lang.reflect.ParameterizedType;
  
public class Main implements Runnable {	
        	
	private static int globalCounter = 0;
	//static field infiList of type ArrayList
    public static ArrayList<String> infiList;
    	
    public static void main(String[] args){
    	
    	Main c = new Main();
    	for(int i=1; i<3; i++) {//create three simultaneous threads
    		Thread t = new Thread(c);
    		t.start();//start the thread
    	}

    	//print infiList to screen
    	System.out.println(infiList);
    	
    }//end main

    //overridden run method
	@Override
	public void run() {
		
		Object This = null;
		synchronized(This) { //forbids interruption
			//of the following block (the "critical section"):
			 int uniqueThreadNumber = globalCounter;
			 System.out.println("Setting uniqueThreadNumber to "
			+ uniqueThreadNumber );
			globalCounter = globalCounter + 1;	
		}	
		Object is = null;
		synchronized(is) { //forbids interruption
			//of the following block (the "critical section"):
			 int uniqueThreadNumber = globalCounter;
			 System.out.println("Setting uniqueThreadNumber to "
			+ uniqueThreadNumber );
			globalCounter = globalCounter + 2;	
		}	
		Object infinite = null;
		synchronized(infinite) { //forbids interruption
			//of the following block (the "critical section"):
			 int uniqueThreadNumber = globalCounter;
			 System.out.println("Setting uniqueThreadNumber to "
			+ uniqueThreadNumber );
			globalCounter = globalCounter + 3;	
		}		
	}
	
}//end class

could anyone please help me?

[Greg Charles]

Hi Jake, welcome to Java Ranch!

You want to synchronize on infList, not on those three null objects you've defined. Threading is a bit mind bending, especially at first. What you are trying to do is protect some resource (infList is this case) from being accessed by multiple threads at the same time in a way that could cause undesirable results.

Normally the system decides when each thread will get a slice of CPU time to run. Let's say your first thread checked the list, and found "is" was the last entry in it. OK, it thinks, I'll add "infinite" to it. Suddenly it loses its time slice and thread 2 gets to run. Thread 2 sees that "is" is still the last entry and adds "infinite". Then thread 1 gets another time slice, but does it check the last entry again? No, it resumes exactly where it left off, unaware that there have been changes. It therefore inserts "infinite" as well, and your list now has "This", "is", "infinite", "infinite". Ugh! By synchronizing on infList, you tell a thread that it can't run any code in the synchronized block if any other thread has entered that block and not yet exited. In this case, thread 2 gets its time slice as above, but instead of running the code, it blocks waiting for thread 1 to give the all clear by finishing the synchronized code it was running.

I hope that helped!

[Les Morgan]

One of the main things a programmer is required to do is to do an analysis of the code that they write. Does it do the task it was designed to do? If not, what does it do and how does it deviate from what is wanted?

So the first thing I have to ask you is:

What does it do?
How does that deviate from what is wanted?

When you can answer both those questions, then you can ask others for specific help, or even better, why it does....

[Campbell Ritchie]

I always get suspicious when I see the keyword static. Why is that List marked static?

[Jake Jameson]

The list is static as I am required to use a static field inflist of type ArrayList<String>

[Campbell Ritchie]

That is not an explanation for its being static. Ask whoever told you that to explain it. I suspect it is a mistake.

[Les Morgan]

Being a class variable, insures that there is exactly 1 copy of those objects, in case the implementer wants to use the class itself for threading. IMO: a cudo for the teacher to keep his class from asking--"but why don't I see all the thread output in my..."

Campbell Ritchie wrote:That is not an explanation for its being static. Ask whoever told you that to explain it. I suspect it is a mistake.

[Chris Hurst]

This doesn't look like a good exercise.

Just looking at the specs if it runs forever isn't the result out of memory error as it seems to suggest you should loop forever (albeit the code posted doesn't loop). Am I miss reading this ? It would have been better if each thread was allowed say 500 adds each then you join and show the results. If someone asked me to do this as spec'ed I'd make so it was parameterized to do n iterations where infinite was a possible setting for n.

I'd have another attempt (using Greg's suggestion to sync on just infiList) and post again.

[Campbell Ritchie]

Les Morgan wrote:Being a class variable, insures that there is exactly 1 copy of those objects . .

Sorry for not noticing that reply earlier. I still don't find that convincing.

[Campbell Ritchie]

Can you synchronize on null?

[Chris Hurst]

Can you synchronize on null?

No its not an object, it just wouldn't work but I think the consensus was he needs to sync on the array.

(You'd expect it to null pointer though I did wonder if any newer java version could pick up the sync on local object is pointless and use escape analysis to make it a noop and the just do nothing with regard to the sync rather than null pointer ?)

[Campbell Ritchie]

I tried it in Java8 with the code at the beginning of this thread and found out:-

System.err.println is not thread‑safe when you get two Exceptions in two threads They were of course null pointer exceptions.