Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Gaurantee in Threads

 
Sudhanshu Mishra
Ranch Hand
Posts: 238
1
Eclipse IDE Fedora Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,
Regarding below code , is the behaviur guaranteed?



The output is

  • 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.

    Just let me know if I am getting it right.

    Thanks.
     
    Campbell Ritchie
    Sheriff
    Pie
    Posts: 49447
    62
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I think you are right, but not certain.
     
    Steve Luke
    Bartender
    Posts: 4181
    22
    IntelliJ IDE Java Python
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.

    For more about the happens-before relationship rules, see this part of the JLS.
     
    Supun Lakshan Dissanayake
    Ranch Hand
    Posts: 135
    Android Java PHP
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.

    I can't guarantee that my answer is 100% correct. so please someone correct me if i'm wrong.

    Thanks!
     
    Steve Luke
    Bartender
    Posts: 4181
    22
    IntelliJ IDE Java Python
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.

    I can't guarantee that my answer is 100% correct. so please someone correct me if i'm wrong.

    Thanks!


    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.
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic