Chris Abbey <[EMAIL PROTECTED]> writes:
> 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
[...]
> but actually a statement of the technology's threading quality (or lack
> thereof as the case may be).
I want to describe the other side of the coin, although it is becoming
off-topic. Leaving as unspecified such details of threading as
whether threads interleave or run in parallel, length of a time slice,
algorithm for picking the next ready thread to run, etc., gives the
implementor the necessary freedom to implement threading in the best
way suited for the situation and the underlying hardware.
For example, if we required threads to interleave, that would be a
waste of SMP; but if we required full parallelism, that would be
meaningless for single-processor computers.
If we specified a time slice that is too long, it would be silly for
fast computers; but if we specified a time slice that is too short, it
would be too much overhead or even impossible for slow computers.
The algorithm for picking one out of many ready-to-run threads for
running should be optimized for the underlying OS and hardware; or,
when JIT-type optimizers become advanced enough, optimized for what
the threads are doing. Also, there is no end to such optimizations;
once in a while there will be some researcher coming up with novel
algorithms and policies.
In my opinion, about only two aspects of threading must be specified:
1. fairness: if a thread is ready-to-run, then it will eventually be
run
2. priority: a ready-to-run thread with a higher priority will be run
at least as often as a ready-to-run thread with a lower priority
--
[If you post a response, no need to cc me; if you cc me, please say so.]
"A variable is free in t if it occurs free in t, and it is bound in t if it
occurs bound in t."
- Ralph-Johan Back and Joakim von Wright (_Refinement Calculus_ pp 61)
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
