Why does the thread 3 execute before thread 2 though iam invoking it before thread 3?

if i am right.. after invoking thread 1 the printmsg1 enters into the synchronized state. thread 2 is put in the stack then thread 3 is put in the stack. so after the thread 1 has finished thread 3 is poped and run. finally thread 2.

if this is the case how do i make them run in the order the threads are invoked? ie after thread 1 releases the block thread 2 must acquire the lock then thread 3.

class printmsg{
	synchronized void printmsg1(String data, int timer){
		System.out.println(data);
		try {
			Thread.sleep(timer);
		} catch (InterruptedException ex) {
			System.out.println(ex);
		}
	}
}
class Welcome implements Runnable{

	Thread t1;
	String data;
	int timer;
	boolean flag;
	printmsg pmsg;

	Welcome(printmsg pmsg, String data, String tName, int time){
		t1 = new Thread(this, tName);
		this.data = data;
		timer = time;
		this.pmsg = pmsg;
		t1.start();
	}

	public void run() {
		pmsg.printmsg1(data, timer);
	}
}
public class Main {
    public static void main(String[] args) {
		printmsg pmsg = new printmsg();
		new Welcome(pmsg, "Thread 1", "Hellowa", 1000);
		new Welcome(pmsg, "Thread 2", "Hellowb", 1000);
		new Welcome(pmsg, "Thread 3", "Hellowc", 1000);
    }
}

Recommended Answers

All 5 Replies

I'm not fluent in Java but threads are typically pre-emptive. Higher priority threads pre-empt lower priority threads. Threads of same priority are at the mercy of the tasking system.

One thought is that those three threads are same priority and as they are created, they are pushed at the front of the thread queue, not the back? So the newest thread is further towards the front of the queue so it gets serviced first?

Threads need a smidgeon of time to get setup, and they don't usually get serviced right away so they others get in front of it in the queue and then their time to get serviced comes up!

You can place an event monitor so that when the thread that was just spawned gets executed, you get the event, then spawn the next one!

Why does the thread 3 execute before thread 2 though iam invoking it before thread 3?

Hi

There are two kinds of memory used in Java. Stack memory and heap memory. Stack memory stores primitive types and the addresses of objects. The object values are stored in heap memory but the address (reference) to the stored objects are stored on the stack.

The timer makes the "stop" after your thread is created so the timer that is created first like in

new Welcome(pmsg, "Thread 1", "Hellowa", 1000);

holds the time 1000 afterwards.

In the meantime the other thread objects are created and there references are put on a stack. The stack works after the LIFO principle (last-in-first-out) so when the first "stop" is over the stack releases the last inputted address first.

If you had 6 objects declared the same way, the output would be like:
Thread 1
Thread 6
Thread 5
Thread 4
Thread 3
Thread 2

If you had 6 objects where you declared the time on #1 to 0 and the rest as in your code to 1000, the output would be like:
Thread 1
Thread 2
Thread 6
Thread 5
Thread 4
Thread 3

If you create some more objects you can play around and see very clearly how it works if you put some objects to time 0 and some to time 1000 or 10000.

Hope this gave you an idea of what is happening.
Good luck =)

You may find the following useful - in summary: when threads of equal priority are scheduled the order is arbitrary (although round-robin scheduling gives them all a chance). Time slicing and multiple CPUs make this a lot less deterministic. In summary summary - you can't assume anything about the order of execution of threads of the same priority.

Thread Scheduling Summary

* Many computers have only one CPU, so threads must share it with other threads. The execution of multiple threads on a single CPU, in some order, is called scheduling. The Java platform supports a simple, deterministic scheduling algorithm called fixed-priority scheduling:
* Each thread has a numeric priority between MIN_PRIORITY and MAX_PRIORITY (constants defined in the Thread class). At any given time, when multiple threads are ready to be executed, the highest-priority thread is chosen for execution. Only when that thread stops or is suspended will a lower-priority thread start executing.
* When all the Runnable threads in the system have the same priority, the scheduler arbitrarily chooses one of them to run.
* The Java platform does not directly time slice. However, the system implementation of threads underlying the Thread class may support time slicing. Do not write code that relies on time slicing.
* A given thread may give up its right to execute at any time by calling the yield method. Threads can yield the CPU only to other threads of the same priority. Attempts to yield to a lower-priority thread are ignored.

http://life.csu.edu.au/java-tut/essential/threads/priority.html

>The Java platform supports a simple, deterministic scheduling
>algorithm called fixed-priority scheduling

Any official links? AFAIK, the JVM specification makes no such claim and leaves the details entirely to the implementation. I personally would be rather cautious in accepting anything which isn't stated in the official docs/ vm specification.

>The Java platform supports a simple, deterministic scheduling
>algorithm called fixed-priority scheduling

Any official links? AFAIK, the JVM specification makes no such claim and leaves the details entirely to the implementation. I personally would be rather cautious in accepting anything which isn't stated in the official docs/ vm specification.

Yes, I agree that you need to be careful where you get this kind of info from , and only Sun is definitive. Sadly, Sun give us almost nothing to go on, and the detailed scheduling algorithms have changed between pre 1.4.2, 1.4.2, and 1.5 (at least), and also vary between OSs.

The following quote is from http://java.sun.com/j2se/1.5.0/docs/guide/vm/thread-priorities.html and strictly applies to Solaris, but the message in this quote is surely a general statement of intent:

General Scheduling Issues: Priority, Yielding, and Monitor Fairness

The Thread.setPriority and Thread.yield methods are advisory. They constitute hints from the application to the JVM. Properly written, robust, platform-independent code can use setPriority() and yield() to optimize the performance of the application, but should not depend on these attributes for correctness. Likewise, no assumptions should be made about the order in which threads are granted ownership of a monitor or the order in which threads wake in response to the notify or notifyAll method. An excellent reference for these topics is Chapter 9, "Threads," in Joshua Bloch's book Effective Java Programming Language Guide.

The source I quoted in my previous post was (I thought) a reasonable summary of the situation (with the possible exception of the sentence you quoted), and sufficient for the purposes of the the OP's question. Unless you know otherwize? :-)

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.