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