Apps Comprehension Question: Thread processing orders, BufferedInputStream

[armai123mai]

When I have a method which creates a thread like this:

public void SendFileThread(final int threadID, final String path){

AsynchUtil.runAsynchronously(new Runnable() {@Override
public void run() {

final File file = new File(path);

byte[] bytes = new byte[(int) file.length()];

try {

BufferedInputStream bis = new BufferedInputStream(new FileInputStream(file));

BufferedOutputStream bos = new BufferedOutputStream(socket.getOutputStream());

bis.read(bytes, 0, bytes.length);

bos.write(bytes, 0, bytes.length);

bos.flush();

ThreadFinish(threadID);

} catch (FileNotFoundException e) {

e.printStackTrace();

} catch (IOException e) {

e.printStackTrace();

} finally {

}
}

});
}


What will happen, when I call that method from the GUI thread serveral times simultaneously, with different parameters? Will the thread called a moment later start being processed after the first called thread has finished, or will both run simultaneously?

I testet this by writing a thread code which sends a file from the path which is given by the parameter. Then I wrote an app with a button, which initializes a socket and then starts that thread 2 times simultaneously with different file path parameters (first one is pointing a text file full of "AAAAA", the second one a text file full of "BBBBB"). I clicked that button and then looked on the server side what was coming in. The result was that the second file data (the "B"-army) was arriving after the last "A" of the A army from the first file.

From this I could assume that the threads are being processed sequentially (one by one) and not simultaneously.

But I am not sure about this. It is possible that the BufferedInputStream is blocking the input stream from the second thread until the first one has finished reading the AAA file in. Could this be happening? Is a thread being blocked, while it cant write data into the buffer, or will it just proceed after given the command to the bufferstream handler or what ever (shall I consider the buffered streaming thing like another thread of its own?).

I really would appreciate some coachings on this.

Thank you

 

[Deleted User]

All your asynchronous threads will run in parallel, and the order in which the threads run isn't predictable. So if you have code which is using a shared resource, then you have to take measures to protect it, especially if the code is changing its state.
(See spoiler section)

However, in your code, if you are reading from different files, then they are not shared resources, so there will be no thread contention. But if your threads are writing to the same output file, then you could quite possible get thread contention, and the result would be unpredictable - e.g. you may get 'AAABABBABBBA' or some other combination. Just because you get 'AAAA' followed by 'BBBB' doesn't mean you would get the same result next time. There's no guarantee on the order of execution for threads running in parallel.

Actually I just noticed that you're using a socket to write the data over the network. This would be a shared resource, but in this case, the system prevents multiple threads from accessing it simultaneously, and generates an exception "socket already in use" if one thread tries to use the socket at the same time as another thread.

Spoiler

In multi-threaded code, we use synchronised blocks, or synchronised objects to control access to shared resources. This allocates a lock to any thread wanting to use a shared resource. When a thread has the lock, no other thread can use it, and must wait until that lock is released.
The technical term for this is a 'monitor', and the lock is called a 'mutex'. Here's the theory:

https://en.wikipedia.org/wiki/Monitor_(synchronization)

That page gives you a shed load of theory behind the monitor, but actually Java makes this dead easy by letting you declare something as 'synchronized'. You normally protect a critical section of code by acquiring a lock, and only allowing one thread at a time to execute code which uses the resource. Some information here if you're interested:

https://www.tutorialspoint.com/java/java_thread_synchronization.htm