Patrick Mauritz wrote:

>Am Donnerstag, den 14.04.2005, 11:37 -0400 schrieb David Shaffer:
>  
>
>>suggesting it.  Really, green threads are not a problem for a server.
>>    
>>
>true, but they limit the usefulness of multicore scenarios, and whatever
>squeak comes up with, those _will_ come.
>  
>
The future of processor architecture isn't clear especially w/ regards
to its impact on the developer.  There is a lot of work in predictive
(actually "speculative") multithreading  Future multicore systems may
combine this with parallelism built in at the "system library" level. 
Current research also seems to favor specialization in these cores: one
for the kernel/scheduler, one for I/O management and a small handful for
user processes, for example, whose parallelism is managed
speculatively.  Really, I don't want to guess.  What we see now are
small SMP machines (4 processors) and some 2 core systems (HT
technologies) w/ parallelism handled entirely by the OS or the
applications developer.  How one best utilizes this really depends on
what their doing.  For web servers in both of these cases I'm happy to
load balance my Squeak/Seaside servers across the processors.  One
running image per processor.  When we get to 10 cores/processors, things
change a bit since now I might want to re-think my low-level
computations to take advantage of the parallelism.  This is why I
specifically indicated that I agree that support for native threads is
something that we need to keep thinking about.  Still, were a long ways
from "needing" such support.  This is quite different than other
development platform's thread implementations.  Green threads in Java,
for example, had the problem that one blocking call blocked all of the
threads (since the OS blocked the process).  This doesn't happen in
Squeak where the VM uses non-blocking I/O and semaphores.

BTW, I attended a recent lecture of Guri Sohi, fairly well known in
microprocessor architecture research, who seemed to feel strongly that
putting parallelism in the hands of the applications developer was a big
mistake.  He indicated that far sighted hardware developers are looking
at fixing that...leaving little of the threading issues to the developer
(again, except in the case of OS libraries).    Anyway, one person, one
opinion...still I expect to have a 1024 core machine on my desktop in
some years to come but I have no idea if I'll even need to know or care
about that when I'm writing code.

>what would happen if there were two (or more) interpreter instances
>running in a process (after removing all globals and similar issues)
>that both behave like the current interpreter (doing green thread work),
>just that there are two processes running all the time?
>
>the scheduler would become slightly more complex (as a candidate process
>to switch to might already run), and some things would have to be
>serialized, but otherwise it should have a relatively small impact and
>still work mostly the same across platforms, or not?
>
>  
>
One could probably, with a lot of hard work, make this scheme work. 
There are more problems than just "removing globals" since both
interpreters may be running methods in the same object.  Many of the
Squeak classes are non-thread safe.  It is easy to do what Sun did and
make thread safe wrappers for collections and what not, enabling
developers to write thread safe applications with non thread-safe
collections.  I think, though, that there would be a lot of daemons in
such a system (non thread-safe classes being used in threaded
applications w/o the developers knowledge).  I hope others will chime in
with details here.

David