Gaurantee in Threads

0
1
2
3
4
5
6
7
8
9
0 in other thread
1 in other thread
2 in other thread
3 in other thread
4 in other thread
5 in other thread
6 in other thread
7 in other thread
8 in other thread
9 in other thread

I believe that the output in this case is predictable.But had I put thread.start() before the main methods for loop, it could have unpredictable behaviour because then we would have two call stacks and two runnable threads, and then the execution would not be guaranteed.

Yes, that is correct. The way it is now: with the thread.start() called after the code in the main method, will cause the code to predictably run main() first, then thread.

In Java, it is all about a 'happens before' relationship between lines of code. The basic rules at play are:
(1) 'If x and y are actions of the same thread and x comes before y in program order, then x happens-before y'
and
(2) 'A call to start() on a thread happens-before any actions in the started thread'
and
(3) 'If x happens-before y and y happens-before z, then x happens-before z.'

So, since the loop in the main thread programatically precedes the start() of the second thread, you will be guaranteed that the loop occurs before the thread start() is called (1). And by definition of rule (2), the start() call in the main thread must happen-before the loop (action) in the second thread. The result (3) is that the loop in the main thread happens-before the loop in the second thread.

But, as you mentioned, re-order where that start() gets called and all bets are off.

I think you're right. because you've start the thread after 1st for-loop.
I think thread is like another software.
using threads in java is like you're listening to music while you are browsing internet.
2 tasks at same time. but different processes.

Supun Lakshan Dissanayake wrote:I think you're right. because you've start the thread after 1st for-loop.
I think thread is like another software.
using threads in java is like you're listening to music while you are browsing internet.
2 tasks at same time. but different processes.

No, a Thread is not like different software or a different process. When you create a Thread, you create a thread of execution inside the same process. The big difference here is that memory is shared between threads, but not between processes.

This idea of shared memory has a lot of advantages - for example the JVM and all your classes only have to be loaded once. If you had different processes then each process would have to load their own JVM and classes which would be terribly inefficient. It also allows easy communication between the threads, rather than relatively complicated requirements for inter-process communication.

There are major disadvantages with the shared memory that threads use: and that is one thread can adversely affect the correct behavior of another thread, and that multiple threads affecting the same data can cause inconsistent or nonsense results. And that is why synchronization, data integrity, and access atomicity are such big concerns in threading - and why it is not good enough just to start multiple threads and belief you now have a multi-threaded application. It takes consideration of your data and how it is accessed to produce good multi threaded applications.