Peter Haggar

author
+ Follow
since Jan 03, 2001
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Peter Haggar

Originally posted by nitin kumar:
Hi
i got a problem in multithreading. In my project I have 10 threads and each thread shud run one after another ie 1,2,3,4------,10 after the completion of the 10 thread again the 1 thread shud run.For inter thread communication I know that wait and notify are one means but how to give the preference if many threads are there. Is there anything like thread priority. I will be thankful if someone provides me with code
bye
nitin


To solve this problem you can use what's called specific notificaiton. It's pretty simple and is described, with sample code here.
Peter Haggar

Originally posted by CL Gilbert:

I think I understand why you would say that, though in my experience I never needed it. Though I should use something.


To guarantee that it works, you need to declare the variable volatile, or access if from a synchronized method/block. If you do neither, it might work, but it is not guaranteed to work on all VM implementations.
Peter Haggar

Originally posted by CL Gilbert:
You dont need wait and interrupt. Just make a variable that is checked every loop


This will work only if the variable dontstop is declared volatile.
Peter Haggar
Take a look at my article in the August 1998 issue of Java Report titled "Multithreaded Exception Handling in Java".
Peter Haggar
This creates problems when you want to control the order of execution of waiting threads. You can't rely on priority, or on which thread has been waiting the longest, even on the same JVM. To control the order of waiting threads you can use the specific notification pattern. Details and programming examples are here.
Peter Haggar
Send me your email address and I'll mail you the code.
Peter Haggar

Originally posted by CL Gilbert:

I still highly doubt most JVMs would be violating the spec. This does not mean I am wrong. It just means I doubt it and would be speechless if it were true.


Then you obviously haven't read my post, or run the code I posted, or visited Bill Pugh's web site I linked, or looked at JSR-133. If you had, you would be speechless. Don't take my word for it, run the code. Bill also has a test program to show how sequential consistency is broken.


In any event, the information I gave was correct. It also seems that the information I am receiving is correct.


Your information about volatile was correct based on the spec, but incorrect based on how most VMs implement the spec. I am saying your code doesn't work because most VMs don't implement the spec properly wrt to volatile.


What I wrote is technically the proper way to write your code, but since there are violations, the things which have been pointed out to me sadly, must be respected...


Yes, technically proper based on the spec, but also technically broken based on VM implementations. The bottom line on volatile, on most VMs is this:
1) It is supposed to ensure sequential consistency, however, on most VMs it doesn't. Therefore, there is no guarantee that with multiple threads in the below code, num will be assigned before stop.

2) It is supposed to ensure that 64-bit variables are treated atomically. However, it doesn't on most VMs. volatile does not guarantee atomicity with regard to 64-bit variables on a 32-bit machine.
The bottom line to all this is not to rely on the specified behavior of volatile without testing your VM first. JSR-133 is revising the memory model to address these and other problems.
Peter Haggar
Using both techiques...calling methods to indicate success or failure or relying on uncaughtException() are ways to deal with this. You may be interested in an article I co-authored on this exact subject that is in the August 1998 issue of Java Report. It's online here.
Peter Haggar

Originally posted by KRISH DOSS:

a). does it mean that these variables are initialized twice when instance of the class
is created?.


Yes.
When memory is allocated for an object, all its statics and instance variables are initialized to their default values. That's null for references, false for booleans, and 0 for numerics. Therefore, if the code initializes these same variables to their default values in the constructor, or when they are declared, the initialization happens twice, unless the duplicate initialization is removed by a runtime optimizer. No javac compilers I have tried remove it. For example:

and

Both of these classes are inefficient and generate the same bytecode shown here:

The assignment of i and s do not need to occur, but there is bytecode to do so. Note that local variables have no default value and must be explicitly initialized.
Peter Haggar
22 years ago

Originally posted by Gerd Rosarius:
Hey,
less expensive but less effectiv: Run javac with it's optimization parameter
Example:
javac -O myClass.java
Greetings
H.-Gerd
[ February 15, 2002: Message edited by: Gerd Rosarius ]


-O won't help. It is a no-op on all javac compilers I have used.
Peter Haggar
22 years ago

Originally posted by Alex Zhang:
Sorry Peter, just has verbal problem! We actually want to express the same idea, may be I have wrongly caught the meanings of the words!
Pls forgive my rudeness!!! :roll: :roll:


Alex, No problem...you were not rude. I'm just glad we both see it the same way.
This has been a good thread because the answer to the original question is not clearly defined in the JLS.
Peter Haggar

Originally posted by Alex Zhang:
But we can hardly say that a higher priority thread must be the one being run prior than the one with low priority.


I didn't say this. You are correct. Re-read my posts.


It all depends on the implementation of the thread scheduler. And it relies on the VM implementation.


Correct. Again, we don't disagree.


Normally speaking U are absolutely correct, but there is no guarantee.
Please have a look here for details:
http://java.sun.com/docs/books/tutorial/essential/threads/priority.html


I took a look and it doesn't say anything different from what I've said...namely that the highest priority thread isn't necessarily the one that is running at any given time.
I re-read my posts and they seemed clear to me. What is it I said that made you think I implied a guarantee?
Peter Haggar
I just traded email with Gilad Bracha, the author of the 2nd ed. of the JLS and my assumption was correct. The waiting threads on a synchronized method or block will behave just like I described for waiting threads when you call notify/notifyAll. You have no control over which thread will execute and it is not necessarily the one with the highest priority or the one that has been waiting the longest.
I hope this clears it up.
Peter Haggar


"Just remember that a thread of higher priority will always start first."


This is not true. Threads with higher priority might execute first, but you can't rely on it, even on the same system. For why this is so and how to programmically choose a thread to run when calling notify or notifyAll, see my article here.
The original question is interesting though. My article specifically deals with wait, notify, and notifyAll. The original question isn't about them, but simply about calling a synchronized method with multiple threads.
I looked at the spec and it isn't clear (what's new?) on this point, however you can strongly infer from reading it that the behavior is the same as with notify and notifyAll. That is, if T1 is executing method foo that is synchronized and T2, T3, T4, and T5 call foo, in that order, and block, you cannot predict the order that they will execute foo once T1 releases the lock.
Peter Haggar

Originally posted by Horaci Macias:
Could you tell me how to see the assembler produced by a java code ?


The bytecode is produced by using the javap tool. On a class file named test.class this works on Windows:
javap -c test > test.bc
To see the assembler, the JVM you run with must have a JIT (most do). I took the code above and wrapped it in an infinite loop. I then ran the program and debugged the java process with the Microsoft Visual C++ debugger. When the debugger starts, I break the execution of the program. Since the code I wanted to see is spinning in an infinite loop, it's quite easy to see that code as you step through the assembler.
Peter Haggar
------------------
Senior Software Engineer, IBM
author of: Practical Java
22 years ago