Multithreading
Cees de Groot
cg at cdegroot.com
Mon Mar 28 09:58:49 UTC 2005
On Sun, 27 Mar 2005 18:44:29 -0800, Ross Boylan
<RossBoylan at stanfordalumni.org> wrote:
> This has been a very interesting thread for me. I thought squeak did
> time-slicing. Are other smalltalks the same in not doing timeslicing?
>
The other Smalltalk I know well, VisualWorks, also has 'green threads'. It
does support native multithreading, but it's too hairy for most to bother.
Personally, I think the value of native multithreading is exaggerated.
About the only real use I can see for it is multi-processor systems. Look
at all the restrictions that Java put into threading when starting to
support native multi-threading for some of the hairiness introduced with
it...
> What actions, or types of actions, are necessary to yield control?
>
Explicit yields, waiting for semaphores (most I/O), etcetera. In fact,
unless you're in a tight loop, there's hardly ever reason to explicitely
yield control.
> Sounds as if it would take a big overhaul to get reliable
> multi-threading.
>
Yes. And if you look at the typical time that's needed to do a 'forced
context switch' in native multithreading, you gain some minor advantages
for a very large cost.
Personally, I think that once Squeak has modules/sandboxing/..., it'll be
almost trivial to assign such a part of squeak (which will be almost like
a separate VM) to a separate native thread. This would solve most of the
problems (lockup by one process not relinguishing control being to most
important one) without a lot of the costs.
> I had understood that squeak was being used (via seaside) for web
> servers. How do they manage to deal with processing many things at
> once (I'm assuming they do)?
>
You'll be surprised how well 'green threads' work ;)
More information about the Squeak-dev
mailing list
|