Smalltalk allows multiple lightweight processes (also called threads or tasks) to execute pseudo concurrently. These run within the same address space (in one heavy weight Unix process) and can communicate via shared objects. Process scheduling is priority driven, where scheduling is implemented fully in smalltalk (i.e. all algorithms are open and can be changed if there is a need to do so).
Each process has its own automatically growing stack which is protected against overflow. No stack size definition is needed at process creation time - the system will allocate additional stack memory in reasonable small increments. Stack overflow can be cought (see ``Exceptions and Signals'') and handled gracefully (it is even possible to restart or continue with more stack space after such an exception).
Also, multiple processes can be debugged simulatiously (using the symbolic Debugger) - even while executing concurrently.
The windowing interface makes use of processes, by executing each view in a separate process. This means, that other views are not locked up by one view being debugged or busy (which is the case in pure event driven systems).
The interesting classes are:
Process
represents a thread of control in smalltalk.
An arbitrary number (limited by memory) of processes can execute concurrently
within a smalltalk system.
These processes (also called threads or lightweight processes)
are not implemented as Unix processes,
but instead are created, managed and scheduled by smalltalk itself.
They all run in the same address space; therefore, the same objects can be accessed by different processes.
aBlock fork
aBlock forkAt:priority
aBlock newProcess
aProcess priority
aProcess state
aProcess id
aProcess name
aProcess priority:newPriority
aProcess priorityRange:priorityInterval
aProcess suspend
aProcess resume
aProcess terminate
More details are found in the
"
Process
class documentation".
ProcessorSchedulers
sole instance (named Processor
)
is responsible for scheduling among running processes. In contrast to other
Smalltalk implementations, scheduling is done completely at the smalltalk language level.
This allows for different schedulers to be implemented if required.
Processor
:
Processor activeProcess
Processor activePriority
Processor userSchedulingPriority
Processor userBackgroundPriority
Processor terminateActive
Processor yield
Processor suspend:aProcess
Processor resume:aProcess
More details are found in the
"
ProcessorScheduler
class documentation".
Notice that a semaphore may be only only entered once, even if the aquiring process already owns it. This may lead to deadlocks or difficult coding style if your code is recursive or is entering the critical region in multiple places. For that, a so called RecursionLock is provided. This behaves like a Semaphore, except for the re-entering situation. It allows for the one process which already owns the lock, to reenter a critical region.
Typical use:
Semaphore new
Semaphore forMutualExclusion
RecursionLock new
aSemaphore wait
aSemaphore waitWithTimeOut:seconds
aSemaphore signal
aSemaphoreOrRecursionLock critical:[ ... criticalBlock ...]
Processor signal:aSemaphore onInput:fileDescriptor
Processor signal:aSemaphore onOutput:fileDescriptor
Processor signal:aSemaphore afterSeconds:numberOfSeconds
Delay
and ExternalStream
for portability.
SemaphoreSet
.
More details are found in the
"
Semaphore
" or
"RecursionLock
"
class documentation.
Delay
wraps the above timer based suspend into a portable interface.
(Delay forSeconds:numberOfSeconds) wait
(Delay forMilliseconds:numberOfSeconds) wait
Delay waitForSeconds:numberOfSeconds
More details are found in the
"
Delay
class documentation".
Copyright © 1996 Claus Gittinger Development & Consulting
<info@exept.de>