Multithreaded Squeak WAS: RE: [ENH] Empty return expression
Michael Klein
Mklein at nts.net
Tue Sep 28 23:45:09 UTC 1999
On Tuesday, September 28, 1999 12:30 PM, Stephen Pair
[SMTP:spair at advantive.com] wrote:
> Not that I am aware. Making Smalltalk multi-threaded is tricky. Some
> Smalltalks have taken the approach of making the "Process" concept in
> Smalltalk equate one-for-one with OS threads. I think that approach is very
> bad. First, it's difficult to implement, and second, it's inefficient
> because you have the additional overhead of the OS context switching.
Elliot Miranda on c.l.s. a while back also pointed out that this make
the VM's
scheduling behavior dependant on the OS, and makes it unreproducable.
From Elliot Miranda at :
http://www.dejanews.com/[ST_rn=ps]/getdoc.xp?AN=387224637
On a side-note related to reliability, I belive Java has saddled itself
with a
real albatross in being natively multi-threaded. A natively
multi-threaded VM
*isn't* repeatable, period. And that means its *very* difficult to
debug VM bugs.
It's kind of nice knowing that context switching can occur only at well
defined points.
In Squeak, that would be
Interpreter >># checkForInterrupts
I like Travis' idea of mapping OS threads to Smalltalk
ProcessSchedulers.
Hmmm.
[RelativelyLongIndepentantTask startUp] forkOn: ProcessScheduer new.
Also, there was a book a while ago on Concurrent Smalltalk. It was
pretty interesting.
http://www.amazon.com/exec/obidos/ASIN/9810201125/onlinetoday/
ISBN: 9810201125
Design and Implementation of Concurrent Smalltalk
(World Scientific Series in Computer Science, Vol 21) by Yasuhiko
Yokote
More information about the Squeak-dev
mailing list
|