BAZLEY Sebastian wrote:
> In case anyone is interested, there is a useful description of such issues
> in the O'Reilly book "Java Threads", chapter 6 "Java Thread Scheduling",
> which discusses some popular scheduling implementations.
>
> A couple of suggestions (not tested):
>
> If you don't want to use MIN priority, you may be able to choose a priority
> between MIN and NORM, if this is supported on your target system(s).
> Unfortunately, although there are many different priorities in the JVM,
> these may not all map onto different priorities in a real implementation.
> [Indeed, even MIN and NORM may end up with effectively the same priority,
> depending on the implementation.]
>
> Yield() does not guarantee that another thread will execute; it may be that
> the next eligible thread is the one that is yielding. But if you can
> sprinkle more yield() calls around your code you may get what you want...
Umm if you need to control threads the same book also gives a way to make
your own thread sheadular using a high priority thread to scheduale wich thread
runs
next. If its important to ou I would go this route.
Note though that some platforms do indeed not have any notion of thread
priority.
I believe the Mac platform does not really support thread priorities.
At that point I would suggest running the complex calculation in a diffrent
process and using rmi or
pipes to communicate. I would consider redesing your app into a client server
style application
just on general principals alone with 1.2 the rmi overhead can be removed if
your in the same VM.
Also as far as I'm concerned the whole lack of specification on thread behavior
is a real probelm with
the Java specification. The lack of cross thread exceptions ( signals ) is a
real bummer. Java's exception handling mechanism
has no understanding of threads.
Mike
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
