This is "known behaviour". The thread spec is very vague in regard to how
it is supposed to work. There have been numerous discusions on the list
in the past, check the archives for them. It basically boils down that
there is no gaurentee in the threading spec that multiple threads will
be interleaved (or anything else for that matter). So there is, by design
(or by mis-design depending on your POV), the possibility that a single
CPU bound thread will starve all others. Any code which relies on equal
priority non-blocking cpu bound threads to be time sliced is relying on
non-spec implementation issues and thus is not well written java; it is
also bound to be broken when moving platforms (even on the same hardware).
Please note that this is by no means a statement of your code quality,
but actually a statement of the technology's threading quality (or lack
thereof as the case may be).
At 10:40 10/29/99 -0400, Rich Ibbotson <[EMAIL PROTECTED]> wrote:
>Hi Everyone,
>
> I am seeing strange behavior in the way threads are switched in java
>1.1.7v3. This is on a RedHat Linux 6.0 system (kernel 2.2.5-22, with
>glibc 2.1). I have the jdk and native-threads packages for glibc on X86
>from blackdown.org.
>
>Problem 1: If I start 3 threads at the same priority and none yields or
>blocks on i/o, only the first one to be started gets time. On a Solaris
>machine the three threads share time roughly equally. Is this known
>behavior? Is there a way to choose a different model? I should say
>that this is using green threads.
>
>Problem 2: I tried doing the same thing using native threads, in the
>hope of getting a better time-sharing model. When compiled and run with
>native threads, the behavior is strange enough that I think there must
>be a library mis-match. The main routine usually doesn't sleep for 10
>seconds when it is sent a sleep(10000l) (it sleeps for more like 100ms,
>but very occasionally it will sleep for 10 seconds). Can I re-build the
>native threads part from sources? Or is there a known library problem
>with glibc2.1?
>
>thanks in advance,
>Rich
>[EMAIL PROTECTED]
>
>
>----------------------------------------------------------------------
>To UNSUBSCRIBE, email to [EMAIL PROTECTED]
>with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
>
cabbey at home dot net <*> http://members.home.net/cabbey
I want a binary interface to the brain!
Today's opto-mechanical digital interfaces are just too slow!
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
