Concurrency in Squeak? Is there any?

Peter Crowther pjc at datatec.co.uk
Tue Jan 19 15:57:35 UTC 1999


> Anyway, when I try something that loops for some time, everything locks up
> 
> until the loop finishes. I'm doing this from the Workspace and outputting 
> to Transcript. Might I be doing something wrong or is Squeak just a single
> 
> thread that vanishes into every object you call and you can't do a thing 
> until it comes back (sort of)?
> 
The UI is single-threaded, but it's perfectly possible to create background
processes (see classes Process and ProcessorScheduler, and the Processor
object).  For example:

	[1 to: 10000 do: [:i | nil]. Transcript cr; show 'Bing!'] fork

You will regain control of the UI as soon as the fork completes, and the
other thread will run asynchronously.

However, there are a few problems for us multi-threaded types:

- Processes have priorities, and pre-empt between priority levels, but
processes within a priority level are co-operative; one can still hog the
CPU.  (Anyone implemented pre-emption before I have a go with a
high-priority scheduler process?)

- You will have to do your own locking of objects if they will be accessed
by multiple processes (see class Semaphore)

- The VM itself will not run multiple processes simultaneously, and the
notion of 'Processor activeProcess' is buried very deeply within the image.
This is fast on a uniprocessor, preserves generality, and avoids the
overhead of always locking objects.  However, you get little or no speed
advantage running Squeak on a multiprocessor computer.

- The GUI isn't really process-aware.  For example (in a 2.2 image) a
background thread that causes an error will attempt to open a Debugger, but
that Debugger isn't displayed or scheduled until you click into it --- which
can be disconcerting when you thought that piece of screen was a Workspace!
I'm working on some fixes, but am not an MVC or Morphic guru, so don't
expect them fast :-).

It's quite possible to write heavily multi-threaded systems in Squeak.  I'm
building a multi-user adenture game where the users can dynamically
re-program the server by sending Smalltalk class and method definitions down
the network link.  This has a background thread for each listening socket,
and another for each connected player; I can still use the GUI while the
whole shooting match is running.

		- Peter
--
Peter Crowther





More information about the Squeak-dev mailing list