 |
AppletTalk.com
Java discussions newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Toro
Guest
|
 Posted: Fri Nov 14, 2003 5:56 am Post subject: thread |
 |
|
There are 2 types of threads, A and B, which will call the run method
intermittently,
public void run() {
processing();
}
Suppose now I know the current thread that calls the run() method is of type
A, is it possible to have all the started and in coming type B threads to
wait?
|
|
| Back to top |
|
 |
FISH
Guest
|
| Posted: Fri Nov 14, 2003 10:58 am Post subject: Re: thread |
|
|
"Toro" <spam (AT) spam (DOT) com> wrote
| Quote: | There are 2 types of threads, A and B, which will call the run method
intermittently,
|
public void run() can only be called once per thread, IIRC. (Well,
technically it can be called any number of times 'manually' by your
code - but a thread cannot be re-started once stopped.)
| Quote: |
public void run() {
processing();
}
Suppose now I know the current thread that calls the run() method is of type
A, is it possible to have all the started and in coming type B threads to
wait?
|
Give A higher priorities than B. So long as A never blocks, B should
not get scheduled.
I have the nagging feeling, though, that whatever problem you are trying
to solve, you're going about it the wrong way.
-FISH- ><>
|
|
| Back to top |
|
|
Toro
Guest
|
| Posted: Fri Nov 14, 2003 1:30 pm Post subject: Re: thread |
|
|
| Quote: | Give A higher priorities than B. So long as A never blocks, B should not
get scheduled. |
Actually, I have two LinkedLists to store the threads separately. And the
program checks to see if the list (A) is empty before looking into the
another list (of B). The performance is not good. And so I want to find
other mechanisms to speed out handling thread A. But it seems nothing more
can be done.
|
|
| Back to top |
|
|
Tony Dahlman
Guest
|
| Posted: Tue Nov 18, 2003 6:00 am Post subject: Re: thread |
|
|
Toro wrote:
| Quote: |
Give A higher priorities than B. So long as A never blocks, B should not
get scheduled.
Actually, I have two LinkedLists to store the threads separately. And the
program checks to see if the list (A) is empty before looking into the
another list (of B). The performance is not good. And so I want to find
other mechanisms to speed out handling thread A. But it seems nothing more
can be done.
|
Toro, I actually like your method better than relying on priorities. As
JoeKing(?) said, it "should" work. Problem is that thread groups and the
priority API seems to be too platform dependent, not just JVM dependent.
At least you have full control of what runs and what waits, even if it is
slow. Or else you might want to try a thread class like this:
-----------------------------------------------------------------
public class Job implements Runnable {
private char priority;
private JobControl monitor = null;
public Job( char priority, JobControl monitor ) {
this.priority = priority;
this.monitor = monitor;
}
public void run() {
monitor.checkOKtoRun( priority );
System.out.println("Processing priority " +priority+ " job." );
doProcessing();
monitor.reportDone( priority );
}
}
-----------------------------------------------------------------------
Then you just need to write the JobControl class. It will instantiate your
Runnables, decide whether they are 'A' or 'B', and then start() all the
threads. e.g.:
char priority = // random choice of A or B
Job job = new Job( priority, this );
new Thread( job ).start();
The other things to put in JobControl are the two synchronized methods
referred to in your threads' run() methods, one that conditionally wait()s
and the other that conditionally notify()s.
There are other ways, but I *like* this pattern for thread control, i.e.
starting all the threads by blocking on a synchronized method in the
monitor. Now the monitor can contain all the logic for deciding which
threads to run first.
Before exiting run() you'll want to call a second method in the monitor
that responds to the fact that a thread is finishing by optionally
notify()ing one of the threads that remain blocked.
Here you might use the first method to let all A's run immediately, but
call wait() otherwise, forcing all the B's to block.
You could keep a count of the A threads as they start. As they exit,
you could decrement the count. When the count is zero, you can start
notify()ing the B threads.
When I tested this concept, I wrote a doProcessing() method that just
sleep()s from 200 to 1200 msecs. With 10 threads typical output was:
-----------------------------------------------------------
Processing priority A job in about 583 msecs.
Processing priority A job in about 1180 msecs.
Processing priority A job in about 426 msecs.
Processing priority A job in about 272 msecs.
Processing priority A job in about 355 msecs.
Processing priority B job in about 449 msecs.
Processing priority B job in about 1112 msecs.
Processing priority B job in about 446 msecs.
Processing priority B job in about 879 msecs.
Processing priority B job in about 610 msecs.
------------------------------------------------------------
Bottom line, it can get a little deep but this will no doubt be more
efficient than what it sounds like you are trying. Also, you will be
able to logically think through and predict exactly which threads will
run and in what order. You will then notice how you can further improve
performance, e.g., by launching the B's to run nearly concurrently.
Regards, Tony Dahlman
--
---------------------------------------
a(nospace)dahlman(at)attglobal(dot)net
|
|
| Back to top |
|
|
FISH
Guest
|
| Posted: Wed Nov 19, 2003 1:01 pm Post subject: Re: thread |
|
|
Tony Dahlman <adahlman (AT) jps (DOT) net.invalid> wrote
| Quote: | Toro wrote:
Give A higher priorities than B. So long as A never blocks, B should not
get scheduled.
Actually, I have two LinkedLists to store the threads separately. And the
program checks to see if the list (A) is empty before looking into the
another list (of B). The performance is not good. And so I want to find
other mechanisms to speed out handling thread A. But it seems nothing more
can be done.
Toro, I actually like your method better than relying on priorities. As
JoeKing(?) said, it "should" work. Problem is that thread groups and the
priority API seems to be too platform dependent, not just JVM dependent.
|
AFAIK the priority stuff works identically on all Java implementations,
and is mandated to do so. The way threads are scheduled within a
priority 'level' is platform independent, but the fact that an unblocked
higher priority thread will always get CPU over an unblocked lower
priority thread can be relied upon.
Java does not schedule lower priority threads unless all threads of a
higher priority level are blocked. Exactly how it picks between valid
threads of the same level, and how long they get to run, *can* differ
from JVM to JVM! What that amounts to is that if threads in one list
have a higher priority than threads in the other list, then the higher
priority threads will always win out ... however you may not be able to
control the order in which threads from a given list 'execute' (only
that the higher list will always execute in preference to the lower
list!)
If you get ahold of O'Reilly's Java Threads book (written by one of
the software engineers at Sun IIRC) you'll find all kinds of examples
for controlling thread scheduling in very sophisticated ways.
-FISH- ><>
|
|
| Back to top |
|
|
Tony Dahlman
Guest
|
| Posted: Sat Nov 22, 2003 3:11 am Post subject: Re: thread |
|
|
FISH wrote:
| Quote: |
Tony Dahlman <adahlman (AT) jps (DOT) net.invalid> wrote
Toro wrote:
Give A higher priorities than B. So long as A never blocks, B should not
get scheduled.
Actually, I have two LinkedLists to store the threads separately. And the
program checks to see if the list (A) is empty before looking into the
another list (of B). The performance is not good. And so I want to find
other mechanisms to speed out handling thread A. But it seems nothing more
can be done.
Toro, I actually like your method better than relying on priorities. As
JoeKing(?) said, it "should" work. Problem is that thread groups and the
priority API seems to be too platform dependent, not just JVM dependent.
AFAIK the priority stuff works identically on all Java implementations,
and is mandated to do so. The way threads are scheduled within a
priority 'level' is platform independent, but the fact that an unblocked
higher priority thread will always get CPU over an unblocked lower
priority thread can be relied upon.
Java does not schedule lower priority threads unless all threads of a
higher priority level are blocked. Exactly how it picks between valid
threads of the same level, and how long they get to run, *can* differ
from JVM to JVM! What that amounts to is that if threads in one list
have a higher priority than threads in the other list, then the higher
priority threads will always win out ... however you may not be able to
control the order in which threads from a given list 'execute' (only
that the higher list will always execute in preference to the lower
list!)
If you get ahold of O'Reilly's Java Threads book (written by one of
the software engineers at Sun IIRC) you'll find all kinds of examples
for controlling thread scheduling in very sophisticated ways.
-FISH-
|
Okay, but you can see why I suggest taking control of thread scheduling
in your own code, rather than relying on the Java spec, after reading
comments like this:
The native threading model refers to implementations that access the threading model
available on the specific operating system. In the industry today, operating systems where the JVM implements the native
threading model, (Solaris, HP-UX and Win32) all support
kernel threads. This allows Java applications to run in parallel as provided for by the
underlying operating system and the number of available CPUs. They usually have higher
performance due to this capability of true parallelism. However, due to the variation
in these operating systems' kernel threads support, the JVM implementing a native threads
model can have unpredictable results from platform to platform. For the purpose of
comparison, the remainder of this section will discuss the native threads scheduling
implementations for Win32, Solaris and HP-UX.
This from:
http://h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,1701,390,00.html
Hopefully, you are right. But if it was platform dependent in the past, can one
rely on the hope that it will be so in the future? And, of course, there is some
debate about *now* to be considered as well?!
Regards, Tony Dahlman
---------------------------------------
a(nospace)dahlman(at)attglobal(dot)net
|
|
| Back to top |
|
|
FISH
Guest
|
| Posted: Mon Nov 24, 2003 11:35 am Post subject: Re: thread |
|
|
Tony Dahlman <adahlman (AT) jps (DOT) net.invalid> wrote
| Quote: | Hopefully, you are right. But if it was platform dependent in the past, can one
rely on the hope that it will be so in the future? And, of course, there is some
debate about *now* to be considered as well?!
|
From what you've written it looks like you are getting confused between
thread priorities and scheduling. Threads are organised into 'bands'
based upon their priority - forming a kind of irregular 2D array of
threads. All threads of a similar priority are banded together into a
list with other threads of the same priority.
What Java *does* promise, and has promised right from JDK 1.0x, is that
a thread will only be scheduled if all threads in higher priority list
are not capable of being scheduled. If a thread in a higher priority
list changes into a state where it is runnable, it immediately super-
ceeds the current (lower priority) thread.
What Java *does not* promise (what it leaves up to the platform) is
how 'runnable' threads of the same list are scheduled, should the
highest priority list with a schedule-able thread have more than one
such thread available. The order in which these threads of equal
priority are choosen, and the manner by which CPU time is shared
between them, is left up to the underlying platform to decide.
What this gives you is the ability to manage at a kind-of 'strategic
level' how your software will be threaded, while leaving the nitty-
gritty level up to the underlying OS. Fortunately a strategic level
control of threading is all you need to solve most problems - including
the one which initiated this 'thread' (excuse the pun! :-)
-FISH- ><>
|
|
| Back to top |
|
|
Tony Dahlman
Guest
|
| Posted: Thu Nov 27, 2003 2:02 am Post subject: Re: thread |
|
|
FISH wrote:
| Quote: |
Tony Dahlman <adahlman (AT) jps (DOT) net.invalid> wrote
Hopefully, you are right. But if it was platform dependent in the past, can one
rely on the hope that it will be so in the future? And, of course, there is some
debate about *now* to be considered as well?!
From what you've written it looks like you are getting confused between
thread priorities and scheduling. Threads are organised into 'bands'
based upon their priority - forming a kind of irregular 2D array of
threads. All threads of a similar priority are banded together into a
list with other threads of the same priority.
What Java *does* promise, and has promised right from JDK 1.0x, is that
a thread will only be scheduled if all threads in higher priority list
are not capable of being scheduled. If a thread in a higher priority
list changes into a state where it is runnable, it immediately super-
ceeds the current (lower priority) thread.
What Java *does not* promise (what it leaves up to the platform) is
how 'runnable' threads of the same list are scheduled, should the
highest priority list with a schedule-able thread have more than one
such thread available. The order in which these threads of equal
priority are choosen, and the manner by which CPU time is shared
between them, is left up to the underlying platform to decide.
What this gives you is the ability to manage at a kind-of 'strategic
level' how your software will be threaded, while leaving the nitty-
gritty level up to the underlying OS. Fortunately a strategic level
control of threading is all you need to solve most problems - including
the one which initiated this 'thread' (excuse the pun! :-)
-FISH-
|
If only Captain Sulu could simply "make it so".... Especially, I would
enjoy the part about "a thread in a higher priority list...immediately
supercedes the current (lower priority) thread."
And the message about handling these things at a strategic level
whenever possible is enticing, and generally very good advice. I remember
the first freeware C-compiler MASM. When the author was asked why he
wrote it in BASIC, he said, "because I'm not crazy." And the wonderful
Java IDE, VisualAge, was written in Samlltalk. Etc.
Anyway, I could not get your advice to work. (Mine does.) Here is
code that, if I understand you correctly, should work, followed by output
that probably saddens us both:
--------------------------------------------------------------------
public class PriorityJobControl {
public PriorityJobControl( int nbrOfJobs ) {
for( int i=0; i < nbrOfJobs; i++ ) {
double rand = Math.random();
char name = ( rand >= 0.5 ? 'A' : 'B' );
PriorityJob job = new PriorityJob( name );
if( name == 'A' ) {
Thread aThread = new Thread( job );
aThread.setPriority( Thread.NORM_PRIORITY + 1 );
aThread.start();
} else {
Thread bThread = new Thread( job );
bThread.setPriority( Thread.NORM_PRIORITY );
bThread.start();
}
}
}
public static void main(String[] args) {
new PriorityJobControl( 10 );
}
}
class PriorityJob implements Runnable {
private char name;
private long delay = (long)(Math.random()*1000.0+200.0);
public PriorityJob( char name ) {
this.name = name;
}
public void run() {
System.out.println("Processing priority " + name
+ " job in about " + delay + " msecs." );
doProcessing();
}
private void doProcessing() {
try{
Thread.sleep( delay );
} catch( InterruptedException ignored ) { }
}
}
/* Typical output:
Processing priority B job in about 824 msecs.
Processing priority B job in about 294 msecs.
Processing priority A job in about 685 msecs.
Processing priority A job in about 602 msecs.
Processing priority A job in about 1004 msecs.
Processing priority A job in about 305 msecs.
Processing priority B job in about 400 msecs.
Processing priority A job in about 455 msecs.
Processing priority A job in about 731 msecs.
Processing priority B job in about 968 msecs.
*/
----------------------------------------------------------------------------
Maybe you can footnote your comments about how I was confused by
indicating exactly how we are supposed to write the kind of strategic
code you recommend, which can "solve most problems - including" this one.
Regards, Tony Dahlman
---------------------------------------
a(nospace)dahlman(at)attglobal(dot)net
|
|
| Back to top |
|
|
Tony Dahlman
Guest
|
| Posted: Thu Nov 27, 2003 3:49 am Post subject: Re: thread |
|
|
Tony Dahlman wrote:
| Quote: |
And the message about handling these things at a strategic level
whenever possible is enticing, and generally very good advice. I remember
the first freeware C-compiler MASM. When the author was asked why he
wrote it in BASIC, he said, "because I'm not crazy." And the wonderful
Java IDE, VisualAge, was written in Samlltalk. Etc.
|
Sorry, I guess that was an Assembly Language compiler, and maybe the name
was CASM. Can't remember anymore. So maybe I am confused, but I still can't
get your advice to work in Java. Please do let me know of your advice really
does work "since JDK 1.x" and maybe post some code. We'll be thankful.
Tony Dahlman
---------------------------------------
Don't spam me. I'm in California and we'll find you and put you in jail.
a(nospace)dahlman(at)attglobal(dot)net
|
|
| Back to top |
|
|
FISH
Guest
|
| Posted: Thu Nov 27, 2003 3:20 pm Post subject: Re: thread |
|
|
Tony Dahlman <adahlman (AT) jps (DOT) net.invalid> wrote
| Quote: | FISH wrote:
If only Captain Sulu could simply "make it so".... Especially, I would
enjoy the part about "a thread in a higher priority list...immediately
supercedes the current (lower priority) thread."
And the message about handling these things at a strategic level
whenever possible is enticing, and generally very good advice. I remember
the first freeware C-compiler MASM. When the author was asked why he
wrote it in BASIC, he said, "because I'm not crazy." And the wonderful
Java IDE, VisualAge, was written in Samlltalk. Etc.
Anyway, I could not get your advice to work. (Mine does.) Here is
code that, if I understand you correctly, should work, followed by output
that probably saddens us both:
|
http://www.oreilly.com/catalog/jthreads2/
This book was written by two Sun engineers who work on the Java
project, and contains examples which should answer the problems you
are having understanding threads. It explains how threading works,
and how it works in Java, which functionality is mandated by the Java
spec and which is left up to the OS. It includes many examples of
writing robust threaded code - including IIRC one or two which parallel
the problem you are trying to fix.
-FISH- ><>
|
|
| Back to top |
|
|
Tony Dahlman
Guest
|
| Posted: Sun Dec 07, 2003 5:18 am Post subject: re: thread |
|
|
FISH wrote:
| Quote: |
Tony Dahlman <adahlman (AT) jps (DOT) net.invalid> wrote
FISH wrote:
If only Captain Sulu could simply "make it so".... Especially, I would
enjoy the part about "a thread in a higher priority list...immediately
supercedes the current (lower priority) thread."
And the message about handling these things at a strategic level
whenever possible is enticing, and generally very good advice. I remember
the first freeware C-compiler MASM. When the author was asked why he
wrote it in BASIC, he said, "because I'm not crazy." And the wonderful
Java IDE, VisualAge, was written in Samlltalk. Etc.
Anyway, I could not get your advice to work. (Mine does.) Here is
code that, if I understand you correctly, should work, followed by output
that probably saddens us both:
http://www.oreilly.com/catalog/jthreads2/
This book was written by two Sun engineers who work on the Java
project, and contains examples which should answer the problems you
are having understanding threads. It explains how threading works,
and how it works in Java, which functionality is mandated by the Java
spec and which is left up to the OS. It includes many examples of
writing robust threaded code - including IIRC one or two which parallel
the problem you are trying to fix.
-FISH-
|
Found 31 matches.
Searched 147 files.
This is the result of a search of Wong's and Oaks's downloadable
source code for the word "priority". The majority of matches were
in an example of "CPU scheduling." The example comes to life after
you load C libraries that are different for Win and Solaris.
The other examples use Thread.MAX_PRIORITY and setDaemon() crutches.
Of course, this was my original advice to the OP. To overcome
platform and JVM dependence issues, it really is best to take full
control of your threads when managing more than one or two in your code.
Also, if you are going to disparage someone who disagrees with you,
and who posts code to prove his/her point, you should back it up with
concrete example code that supports your point of view. And if you
cite a reference like Oaks and Wong's book, you better have read it,
and carefully. Excerpt:
---------------------------------------------------------
public class CPUSupport {
static boolean loaded = false;
static {
try {
System.loadLibrary("CPUSupportWin");
loaded = true;
} catch (Error e) {
try {
System.loadLibrary("CPUSupportSolaris");
loaded = true;
} catch (Error err) {
System.err.println("Warning: No platform library for CPUSupport");
}
}
}
private static native int getConcurrencyN();
private static native void setConcurrencyN(int i);
private static native int getNumProcessorsN();
public static int getConcurrency() {
if (!loaded)
// Assume green threads
return 1;
return getConcurrencyN();
}
public static void setConcurrency(int n) {
if (loaded)
setConcurrencyN(n);
}
public static int getNumProcessors() {
if (!loaded)
// Assume green threads
return 1;
return getNumProcessorsN();
}
}
--------------------------------------------------------------
Regards, Tony Dahlman
---------------------------------------
a (no spam)d ahlman( a t )att global( d o t )ne t
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
