We Keep Coding

Join method of thread

I noticed funny behaviour of Join method which is very confusing, Multithreading is possibly obsolete and outdated (after lambda/streams of java 8 ) but still curious to find out if I am missing something, never used threading in real time projects.
class JoinDemoThread1 implements Runnable {
String threadName;
#Override
public void run() {
for (int i = 0; i < 5; i++) {
System.out.println("Testing in demothread1=" + i);
}
}
}
class JoinDemoThread2 implements Runnable {
#Override
public void run() {
for (int i = 0; i < 5; i++) {
System.out.println("Testing in demothread2=" + i);
}
}
}
public class JoinDemo {
public static void main(String args[]) {
JoinDemoThread1 joinDemoThread1 = new JoinDemoThread1();
JoinDemoThread2 joinDemoThread2 = new JoinDemoThread2();
Thread demoThread1 = new Thread(joinDemoThread1);
Thread demoThread2 = new Thread(joinDemoThread2);
demoThread1.start();
demoThread2.start();
// wait for threads to end
try {
demoThread1.join();
demoThread2.join();
} catch (Exception e) {
System.out.println("Interrupted");
}
System.out.println("Ending Main program.");
}
}

Output when running the given code:
Testing in demothread1=0
Testing in demothread1=1
Testing in demothread1=2
Testing in demothread1=3
Testing in demothread1=4
Testing in demothread2=0
Testing in demothread2=1
Testing in demothread2=2
Testing in demothread2=3
Testing in demothread2=4
Ending Main program.
Sure it looks like there's no multi-threading going on at all. This is because your thread finishes so fast that there's no reason for the scheduler to interleave threads. If there's a more intensive process, you will see a more expected output.
For example when delaying threads a bit:
class JoinDemoThread2 implements Runnable {
#Override
public void run() {
for (int i = 0; i < 5; i++) {
try {
Thread.sleep(500);
} catch (InterruptedException ignored) {}
System.out.println("Testing in demothread2=" + i);
}
}
}
The output will be:
Testing in demothread2=0
Testing in demothread1=0
Testing in demothread1=1
Testing in demothread2=1
Testing in demothread1=2
Testing in demothread2=2
Testing in demothread1=3
Testing in demothread2=3
Testing in demothread1=4
Testing in demothread2=4
Ending Main program.

background service call inside for loop in java?

I hope I can explain the problem in proper way :)
I have an array of object (handleData).I get them from DB. I want to send them to server by calling service for each one individually.
I put the service in a for loop to send all handleData (refer to code) .
Calling service is done a background . the response of each may not come as they sent orderly. and I have to do some update for each handleData I send.
problem : when the response comes I am not sure that if the regarded action (update of record) is done to the exact handleData that I want/sent properly.
private void sendDataOfTemplates() {
ArrayList<FormHandleData> formHandleDatas = FormHandleData.getDatasFromDB(getContext(), 12, EnumDataStatusOfServer.NoSTATUS.getIntValue(),-1);// true means >> to send / -1 means no limit
try {
if (formHandleDatas != null && formHandleDatas.size() != 0) {
for (int i = 0; i < formHandleDatas.size(); i++) {
final FormHandleData handleData = formHandleDatas.get(i);
if (handleData.status_in_server == EnumDataStatusOfServer.OPEN.getIntValue())
if (handleData.status_in_app == EnumDataStatusInApp.SAVED.getIntValue() || handleData.status_in_app == EnumDataStatusInApp.EDITED.getIntValue()) {
ServiceHelper.getInstance().sendDataOfTemplates(new ServiceHelper.ResponseListener() {
#Override
public void onResponse(String response) {
try {
SimpleResponse simple_response = new Gson().fromJson(response, SimpleResponse.class);
if (simple_response.isSuccessful()) {
handleData.status_in_app = EnumDataStatusInApp.SENT.getIntValue();
FormHandleData.UpdateDataTemplatesInDB(handleData, getContext(),false);
} else {
}
} catch (Exception e) {
}
}
#Override
public void onErrorResponse(VolleyError error) {
}
}, handleData);
}
}
}
} catch (Exception e) {
}
}

problem : when the response comes I am not sure that if the regarded action (update of record) is done to the exact handleData that I want/sent properly.
If I understand correctly, you are asking if the surrounding local variable handleData which is being accessed by your anonymous ServiceHelper.ResponseListener subclass will always be the same object instance even though in the next for cycle the value of that variable will be different. The answer is yes. So you don't need to worry.
If you want to know more about how anonymous classes can capture variables from a surrounding scope, please read this part of the Oracle's Java tutorial, which says:
An anonymous class has access to the members of its enclosing class.
An anonymous class cannot access local variables in its enclosing scope that are not declared as final or effectively final.
So the fact that the surrounding variable can be accessed means it is (effectively) final from the perspective of the anonymous class, i.e. it does not change.
Here is a little demonstration using multiple threads:
package de.scrum_master.app;
public class WhoDoesWhat {
private String name;
private final String action;
public WhoDoesWhat(String name, String action) {
this.name = name;
this.action = action;
}
public String getName() {
return name;
}
#Override
public String toString() {
return name + " -> " + action;
}
}
package de.scrum_master.app;
import java.util.ArrayList;
import java.util.List;
import java.util.Random;
public class Application {
private static final Random RANDOM = new Random();
public static void main(String[] args) {
List<WhoDoesWhat> peopleDoingSomething = new ArrayList<>();
peopleDoingSomething.add(new WhoDoesWhat("Galileo", "discover moons of Jupiter"));
peopleDoingSomething.add(new WhoDoesWhat("Johannes", "determine the laws of planetary motion"));
peopleDoingSomething.add(new WhoDoesWhat("Albert", "explain the precession of Mercury"));
peopleDoingSomething.add(new WhoDoesWhat("Edwin", "notice something odd about recession speeds of galaxies"));
for (WhoDoesWhat personDoingSomething : peopleDoingSomething) {
new Thread(() -> {
System.out.println("START " + personDoingSomething);
try {
int waitCycles = 1 + RANDOM.nextInt(10);
for (int cycle = 0; cycle < waitCycles; cycle++) {
System.out.println(" " + personDoingSomething.getName() + " is still being busy");
Thread.sleep(250);
}
} catch (InterruptedException e) {
}
System.out.println("STOP " + personDoingSomething);
}).start();
}
}
}
The console log could look like this:
START Johannes -> determine the laws of planetary motion
START Albert -> explain the precession of Mercury
START Galileo -> discover moons of Jupiter
START Edwin -> notice something odd about recession speeds of galaxies
Albert is still being busy
Johannes is still being busy
Edwin is still being busy
Galileo is still being busy
Galileo is still being busy
Edwin is still being busy
Johannes is still being busy
Albert is still being busy
Edwin is still being busy
Galileo is still being busy
Albert is still being busy
STOP Johannes -> determine the laws of planetary motion
Edwin is still being busy
Galileo is still being busy
Albert is still being busy
Galileo is still being busy
STOP Edwin -> notice something odd about recession speeds of galaxies
STOP Albert -> explain the precession of Mercury
Galileo is still being busy
Galileo is still being busy
Galileo is still being busy
STOP Galileo -> discover moons of Jupiter

you can send them one by one when each one is finished like recursive methods. hope this work for you..

problem : when the response comes I am not sure that if the regarded action (update of record) is done to the exact handleData that I want/sent properly.
I know it's an old thread but just wanna help........
In order to find out that the returning handleData corresponds to which element of formHandleDatas ArrayList, you can send an id (which is unique to each one of the elements of the array list) alongside handleData to the server and send it back to the client whenever server returns the result. In this way it will be possible to find the exact handleData. Here I have refactored your code a little bit.
private void sendDataOfTemplates() {
Map<Integer, FormHandleData> formHandleDataMap = FormHandleData.getDatasFromDBAsMap();
try {
if (formHandleDataMap != null && formHandleDataMap.size() != 0) {
formHandleDataMap.forEach((key, handleData) -> {
if (handleData.getStatusInServer() == FormHandleData.EnumDataStatusOfServer.OPEN.ordinal())
if (handleData.getStatusInApp() == FormHandleData.EnumDataStatusInApp.SAVED.ordinal() ||
handleData.getStatusInApp()== FormHandleData.EnumDataStatusInApp.EDITED.ordinal()) {
ServiceHelper.getInstance().sendDataOfTemplates(
new ServiceHelper.ResponseListener() {
#Override
public void onResponse(String response) {
try {
SimpleResponse simpleResponse = new Gson().fromJson(response, SimpleResponse.class);
FormHandleData currentHandleData = formHandleDataMap.get(simpleResponse.getKey());
if (simpleResponse.isSuccessful()) {
currentHandleData.setStatusInApp(FormHandleData.EnumDataStatusInApp.SENT.ordinal());
FormHandleData.UpdateDataTemplatesInDB(currentHandleData, getContext(), false);
} else {
System.out.println("simple response is not successful");
}
} catch (Exception e) {
System.out.println("exception happened while getting simple response:" + e.getMessage());
e.printStackTrace();
}
}
#Override
public void onErrorResponse() {
}
}, handleData);
}
});
}
} catch (Exception e) {
System.out.println("exception happened:" + e.getMessage());
e.printStackTrace();
}
}
here I've used a Map to handle the unique id I mentioned, actually unique id the key of the handleData entry in the map. hope it helps.

How do i prevent my consumer-threads from removing the last element twice?

Questions:
Why do I get a NoSuchElementException when trying to remove the last
element?
How can I fix that?
I have 3 classes (see below) that add/remove Integers to a LinkedList.
Everything works fine until the removing Threads get to the last element.
It seems like both threads try to remove it. The first one succeeds, the second one can´t.
But I thought the synchronized-method/synchroniced-attribute + !sharedList.isEmpty() would handle that.
Class Producer:
This class is supposed to created random numbers, put them in the sharedList, write to console that it just added a number and stop once it gets interrupted. Only 1 thread of this class is expected.
import java.util.LinkedList;
public class Producer extends Thread
{
private LinkedList sharedList;
private String name;
public Producer(String name, LinkedList sharedList)
{
this.name = name;
this.sharedList = sharedList;
}
public void run()
{
while(!this.isInterrupted())
{
while(sharedList.size() < 100)
{
if(this.isInterrupted())
{
break;
} else
{
addElementToList();
}
}
}
}
private synchronized void addElementToList()
{
synchronized(sharedList)
{
sharedList.add((int)(Math.random()*100));
System.out.println("Thread " + this.name + ": " + sharedList.getLast() + " added");
}
try {
sleep(300);
} catch (InterruptedException e) {
this.interrupt();
}
}
}
Class Consumer: This class is supposed to remove the first element in the sharedList, if it exists. The execution should continue (after being interrupted) until sharedList is empty. Multiple (atleast 2) threads of this class are expected.
import java.util.LinkedList;
public class Consumer extends Thread
{
private String name;
private LinkedList sharedList;
public Consumer(String name, LinkedList sharedList)
{
this.name = name;
this.sharedList = sharedList;
}
public void run()
{
while(!this.isInterrupted())
{
while(!sharedList.isEmpty())
{
removeListElement();
}
}
}
private synchronized void removeListElement()
{
synchronized(sharedList)
{
int removedItem = (Integer) (sharedList.element());
sharedList.remove();
System.out.println("Thread " + this.name + ": " + removedItem + " removed");
}
try {
sleep(1000);
} catch (InterruptedException e) {
this.interrupt();
}
}
}
Class MainMethod: This class is supposed to start and interrupt the threads.
import java.util.LinkedList;
public class MainMethod
{
public static void main(String[] args) throws InterruptedException
{
LinkedList sharedList = new LinkedList();
Producer producer = new Producer("producer", sharedList);
producer.start();
Thread.sleep(1000);
Consumer consumer1 = new Consumer("consumer1", sharedList);
Consumer consumer2 = new Consumer("consumer2", sharedList);
consumer1.start();
consumer2.start();
Thread.sleep(10000);
producer.interrupt();
consumer1.interrupt();
consumer2.interrupt();
}
}
Exception: This is the exact exception I get.
Exception in thread "Thread-2" java.util.NoSuchElementException at
java.util.LinkedList.getFirst(LinkedList.java:126) at
java.util.LinkedList.element(LinkedList.java:476) at
Consumer.removeListElement(Consumer.java:29) at
Consumer.run(Consumer.java:20)

Your exception is rather simple to explain. In
while(!sharedList.isEmpty())
{
removeListElement();
}
sharedList.isEmpty() happens outside of synchronization and so one consumer can still see a list as empty while another consumer has already taken the last element.
The consumer that wrongfully believed it is empty will not try to remove an element that is no longer there which leads to your crash.
If you want to make it threadsafe using a LinkedList you'll have to do every read / write operation atomic. E.g.
while(!this.isInterrupted())
{
if (!removeListElementIfPossible())
{
break;
}
}
and
// method does not need to be synchronized - no thread besides this one is
// accessing it. Other threads have their "own" method. Would make a difference
// if this method was static, i.e. shared between threads.
private boolean removeListElementIfPossible()
{
synchronized(sharedList)
{
// within synchronized so we can be sure that checking emptyness + removal happens atomic
if (!sharedList.isEmpty())
{
int removedItem = (Integer) (sharedList.element());
sharedList.remove();
System.out.println("Thread " + this.name + ": " + removedItem + " removed");
} else {
// unable to remove an element because list was empty
return false;
}
}
try {
sleep(1000);
} catch (InterruptedException e) {
this.interrupt();
}
// an element was removed
return true;
}
The same problem exists within your producers. But they would just create a 110th element or something like that.
A good solution to your problem would be using a BlockingQueue. See the documentation for an example. The queue does all the blocking & synchronization for you so your code does not have to worry.
Edit: regarding 2 while loops: You don't have to use 2 loops, 1 loop loops enough but you'll run into another problem: consumers may see the queue as empty before the producers have filled it. So you either have to make sure that there is something in the queue before it can be consumed or you'll have to stop threads manually in other ways. You thread.sleep(1000) after starting the producer should be rather safe but threads are not guaranteed to be running even after 1 second. Use e.g. a CountDownLatch to make it actually safe.

I am wondering why you are not using the already existing classes that Java offers. I rewrote your program using those, and it becomes much shorter and easier to read. In addition the lack of synchronized, which blocks all threads except for the one who gets the lock (and you even do double synchronization), allows the program to actually run in parallel.
Here is the code:
Producer:
public class Producer implements Runnable {
protected final String name;
protected final LinkedBlockingQueue<Integer> sharedList;
protected final Random random = new Random();
public Producer(final String name, final LinkedBlockingQueue<Integer> sharedList) {
this.name = name;
this.sharedList = sharedList;
}
public void run() {
try {
while (Thread.interrupted() == false) {
final int number = random.nextInt(100);
sharedList.put(number);
System.out.println("Thread " + this.name + ": " + number);
Thread.sleep(100);
}
} catch (InterruptedException e) {
}
}
}
Consumer:
public class Consumer implements Runnable {
protected final String name;
protected final LinkedBlockingQueue<Integer> sharedList;
public Consumer(final String name, final LinkedBlockingQueue<Integer> sharedList) {
this.name = name;
this.sharedList = sharedList;
}
public void run() {
try {
while (Thread.interrupted() == false) {
final int number = sharedList.take();
System.out.println("Thread " + name + ": " + number + " taken.");
Thread.sleep(100);
}
} catch (InterruptedException e) {
}
}
}
Main:
public static void main(String[] args) throws InterruptedException {
final LinkedBlockingQueue<Integer> sharedList = new LinkedBlockingQueue<>(100);
final ExecutorService executor = Executors.newFixedThreadPool(4);
executor.execute(new Producer("producer", sharedList));
Thread.sleep(1000);
executor.execute(new Consumer("consumer1", sharedList));
executor.execute(new Consumer("consumer2", sharedList));
Thread.sleep(1000);
executor.shutdownNow();
}
There are several differences:
Since I use a concurrent list, I do not have to care (much) about synchronization, the list does that internally.
As this list uses atomic locking instead of true blocking via synchronized it will scale much better the more threads are used.
I do set the limit of the blocking queue to 100, so even while there is no check in the producer, there will never be more than 100 elements in the list, as put will block if the limit is reached.
I use random.nextInt(100) which is a convenience function for what you used and will produce a lot less typos as the usage is much clearer.
Producer and Consumer are both Runnables, as this is the preferred way for threading in Java. This allows to later on wrap any form of thread around them for execution, not just the primitive Thread class.
Instead of the Thread, I use an ExecutorService which allows easier control over multiple threads. Thread creation, scheduling and other handling is done internally, so all I need to do is to choose the most appropriate ExecutorService and call shutdownNow() when I am done.
Also note that there is no need to throw an InterruptedException into the void. If the consumer/producer is interrupted, that is a signal to stop execution gracefully as soon as possible. Unless I need to inform others "behind" that thread, there is no need to throw that Exception again (although no harm is done either).
I use the keyword final to note elements that won't change later on. For once this is a hint for the compiler that allows some optimizations, it as well helps me to prevent an accidental change of a variable that is not supposed to change. A lot of problems can be prevented by not allowing variables to change in a threaded environment, as thread-issues almost always require something to be read and written at the same time. Such things cannot happen if you cannot write.
Spending some time to search through the Java library for the class that fits your problem the best usually solves a lot of trouble and reduces the size of the code a lot.

Try to switch places of
while(!sharedList.isEmpty())
and
synchronized(sharedList)
I don't think you need synchronized on removeListElement().

Each Thread using unique ID and releasing it for reuse

Below is the code in which in the run method, I am always trying to get unique id from the availableExistingIds and releasing it at the same moment by making a linked list order, but in certain cases I found out that, I am getting NoSuchElementException and id is zero few times which I think should not be the case anytime.
class IdPool {
private final LinkedList<Integer> availableExistingIds = new LinkedList<Integer>();
public IdPool() {
for (int i = 1; i <= 1000; i++) {
availableExistingIds.add(i);
}
}
public synchronized Integer getExistingId() {
return availableExistingIds.removeFirst();
}
public synchronized void releaseExistingId(Integer id) {
availableExistingIds.add(id);
}
}
class ThreadNewTask implements Runnable {
private IdPool idPool;
private int id;
public ThreadNewTask(IdPool idPool) {
this.idPool = idPool;
}
public void run() {
try {
id = idPool.getExistingId();
//Anything wrong here?
if(id==0) {
System.out.println("Found Zero");
}
someMethod(id);
} catch (Exception e) {
System.out.println(e);
} finally {
idPool.releaseExistingId(id);
}
}
// This method needs to be synchronized or not?
private synchronized void someMethod(Integer id) {
System.out.println("Task: " +id);
// and do other calcuations whatever you need to do in your program
}
}
Problem Statement:-
How can I avoid this zero id case here in my code? One scenario under which I can get id = 0 is when the id pool is exhausted (empty). When that happens, the line:
id = idPool.getExistingId();
will fail with a NoSuchElementException. In this case, the finally block will run:
idPool.releaseExistingId(id);
But id will still have its default value of 0 since the first line failed. So I end up "releasing" 0 and adding it back to the id pool even though it was never in the pool to start with. Then a later task could take 0 legitimately. And that's what I don't need. Can anyone suggest me how to overcome this scenario in my code? I always want id should be in the range of 1 to 1000.

why don't you modify your code so that instead of crashing when there are no available ids, it waits for one to become available?
Otherwise, every time you have too much threads working at once, the pool is going to be exhausted, and you are going to have to deal with a lot of failing threads. Also the synchronization work is taken care of for you automatically.
EDIT: here is the modified code
class ThreadNewTask implements Runnable {
private BlockingQueue<Integer> pool;
private int id;
public ThreadNewTask(BlockingQueue<Integer> pool) {
this.pool = pool;
}
public void run() {
try {
id = pool.take();
someMethod(id);
} catch (Exception e) {
System.out.println(e);
} finally {
pool.offer(id);
}
}
private void someMethod(Integer id) {
System.out.println("Task: " +id);
// and do other calcuations whatever you need to do in your program
}
}
And then you initialize the pool with something like this:
LinkedList<Integer> availableExistingIds = new LinkedList<Integer>();
for (int i = 1; i <= 1000; i++) {
availableExistingIds.add(i);
}
BlockingQueue<Integer> pool = new ArrayBlockingQueue<Integer>(1000, false, availableExistingIds);

Problems initiating class that will be updated by multiple threads

Hi i'm trying to create a sever/client program that takes up to 5 clients inputting a string each via multiple server side threads, these strings are to be added to team class ie the Same team, then when the team is full, clients disconnect and the server awaits names for the next Team.
My problem lies in creating an instance of the class Team that each thread updates to..
im not sure where to declare the instance of the class?(it contains a string array[5])
my classes on serverside are currently "TeamServer", "TeamServerThread" "team" "streamSocket"
Below is my "TeamServerThread" currently taking the user string and just adding it to another string.
import java.io.*;
class TeamServerThread implements Runnable {
static String names ="";
MyStreamSocket myDataSocket;
TeamServerThread(MyStreamSocket myDataSocket) {
this.myDataSocket = myDataSocket;
}
public void run( ) {
String newName;
try {
newName = myDataSocket.receiveMessage();
/**/ System.out.println("Name Recieved = "+newName);
updateNames(newName);
// now send the names to the requestor
// wait
myDataSocket.sendMessage(names);
myDataSocket.close();
}// end try
catch (Exception ex) {
System.out.println("Exception caught in thread: " + ex);
} // end catch
} //end run
private synchronized void updateNames (String newName) {
names +=newName + "\n";
// this.team.add(newName);
} // end updateNames
} // end Team
Here is my "Team" class
public class Team
{
public final int TEAM_SIZE = 5;
public String names[] = new String[TEAM_SIZE];
public int num_members = 0;
// waits until five names have arrived
// needs to be synchronized because it can be accessed
// by a number of concurrent threads
synchronized void add(String name)
{
names[num_members] = name;
num_members++;
if (num_members < TEAM_SIZE)
try
{
wait();
}
catch(Exception e) {}
else
try
{
notifyAll();
}
catch(Exception e){}
} // end add
public int Getnum_members()
{
return num_members;
}
} // end Team

All class loading is single threaded and you cannot laod/update a class with multiple threads. However I assume this is not what you mean.
You need to have the Team where every socket can see it. The problem you have is that you haven't synchronized access or replacement of the Team so you could ahve a race condition where too many client try to add themselves to the same team.
I suggest you have some type of TeamCoordinator which is passed to each socket connection which can determine when Team a client should be added to.