Fwd: native threads

Cees de Groot cg at cdegroot.com
Thu Apr 14 20:30:02 UTC 2005


On Thu, 14 Apr 2005 16:52:20 -0300, Ramiro Diaz Trepat  
<ramirodt at gmail.com> wrote:
> Cees, my point is not mooted.  Most web applications use threading.

Again, 50% of them don't, judging by Apache's market share.

> Nobody yet answered why they think it's all right to have to do
> Processor yields in your code for threads of same priority.

Nobody said you need to do them. Uou don't for a typical server app,  
because typical server apps are I/O intensive so your threads will quickly  
hit on places where they are rescheduled.

> Are you really that conservative, I mean to defend teeth and claws
> anachronic green threads?

What's anachronic about them? It's just different. Preemptive and  
cooperative multitasking have coexisted for ages, and they probably both  
have their place. It's a whole lot easier to implement cooperative mt  
(read: less bugs that give you headaches), and it performs much better  
because threads are pre-empted at known points, meaning less context to  
save (I don't know whether you ever did low-level i386 programming, but  
you wonder with all the state saving on a context switch that the CPU has  
time left to do anything else; I did 50k context switches per second  
somewhere in the early '90s with a cooperative multitasking system I  
wrote, that probably was a late 286 or early 386 machine I was working  
on...).

> Wouldn't you be happy with a preemtive system that worked fine?  Not
> having to do fake load balancing haviing different images doing
> different jobs? Not having to ever write Processor yield?
> come on... what would be wrong with native threads?
>
Complexity, complexity, complexity. Plus performance loss. Plus loss of  
platform independence (been there, seen it, got the T-shirt - I was  
involved in all that nastiness that needed to take place inside the JVM in  
order to make it do native threads, and still some of the platform's  
assumptions show through - and that was *after* they killed a whole slew  
of useful operations on the Thread class because they couldn't manage to  
make enough guarantees for every platform). Squeak purports to be 100%  
platform independent. Which means that native threading can at best be an  
addition for some applications that would like it. Lots of work for fringe  
stuff - 90% of the business apps out there will run just fine on a single  
CPU anyway, so why bother?




More information about the Squeak-dev mailing list