aspose file tools*
The moose likes Threads and Synchronization and the fly likes Gaurantee in Threads Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Gaurantee in Threads" Watch "Gaurantee in Threads" New topic
Author

Gaurantee in Threads

Sudhanshu Mishra
Ranch Hand

Joined: May 28, 2011
Posts: 217

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

    Joined: Oct 13, 2005
    Posts: 39868
        
      28
    I think you are right, but not certain.
    Steve Luke
    Bartender

    Joined: Jan 28, 2003
    Posts: 4181
        
      21

    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.


    Steve
    Supun Lakshan Dissanayake
    Ranch Hand

    Joined: Oct 26, 2012
    Posts: 133

    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!


    Are you better than me? Then please show me my mistakes..
    Steve Luke
    Bartender

    Joined: Jan 28, 2003
    Posts: 4181
        
      21

    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.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Gaurantee in Threads