Elegant degradation during runtime in case of deadlock detection or race conditions are non existent in the world of programming languages, yet you can easily think them up (binding some sort of preference to a thread and let the most preferential thread break the lock - experimenting with sleeping a thread for a number of seconds if it seems to race - notifying an 'exception' thread in case of all of this)
It's easy to think them up, but they'd be wrong:-). You can't just revoke one thread's lock arbitrarily. If you think you can, you haven't thought through the consequences: What happens next? The complexity isn't (just) a feature of the language in this case: concurrent programming is tricky.
It's not _inherently_ non-scalable. The problem is of the same order of complexity if the thread scheduler stores and switches states or the program does it explicitly.
It tends to be slower to use a preemptive thread scheduler, as it has less information than the application program, and the effort of switching the thread states is often greater than the effort of explicitly yielding to another task at the application layer -- and possibly because of such secondary benefits as having fewer thread stacks tending to result in greater cache efficiency and less memory usage, but none of this is inherent or invariant, just currently a tendency.
Thread schedulers in the real world are designed for current real world usage and existing CPU architectures. New paradigms can change that.
I would be more than encouraged to study at a univerisity that sacrificed headcount for quality of service to the students that were serious about their studies or research. It's a shame it doesn't happen more.
That wouldn't be testing the quality of the kernel to any great extent. Multiple independent CPU bound user processes should scale close to linearly on most SMP enabled systems, even those with a "giant kernel lock".
Slashdot Mirror
It's not _inherently_ non-scalable. The problem is of the same order of complexity if the thread scheduler stores and switches states or the program
does it explicitly.
It tends to be slower to use a preemptive thread scheduler, as it has less information than the application program, and the effort of switching the
thread states is often greater than the effort of explicitly yielding to another task at the application layer -- and possibly because of such secondary benefits as having fewer thread stacks tending to result in greater cache efficiency and less memory usage, but none of this is inherent or invariant, just currently a tendency.
Thread schedulers in the real world are designed for current real world usage and existing CPU architectures. New paradigms can change that.
I would be more than encouraged to study at a univerisity that sacrificed headcount for quality of service to the students that were serious about their studies or research. It's a shame it doesn't happen more.
That wouldn't be testing the quality of the kernel to any great extent. Multiple independent CPU bound user processes should scale close to linearly on most SMP enabled systems, even those with a "giant kernel lock".