SST provides several programming constructs which help you build concurrent systems. One of these is Actors.

Actors are active objects--they encapsulate notions of concurrency within an object. Method invocation on normal Smalltalk objects is carried out according to passive uniprocessing, sequential semantics. The process sending a message also executes the related method's code.

In contrast, Actors use their own processing resources to satisfy requests. Each Actor thread has its own activity. The threads within an Actor need not have the same activity. A typical activity is to loop forever getting a request, processing it and returning a result. It is also valid for an Actor to simply start up, do some work and then die.

Actors are often useful for managing resource sharing or for coordinating and performing concurrent tasks. Sharing is controlled since all objects internal to the Actor are accessible only though the Actor's API. An Actor's internal objects are only manipulated by its own threads. For example, wrapping a single-threaded Actor around a non-threadsafe object effectively make it thread-safe by serializing all operations.

Actors can admit as much or as little concurrency as their internal structure can handle. Internally they can be strictly single-threaded or multiply threaded. An Actor's threading policy (single-, multi-, pooled, and so on) is independently configurable.

To control some of that concurrency, SST supports explicit suspend and resume style operations. These operations affect all elements of the receiving Actor. Concurrency can be further managed by nesting Actors. Nested Actors, and thus all of their threads, can be started and shut down as atomic units.

User Actors are built by subclassing the class SstActor and by implementing any required domain behavior. You use the concurrency control constructs (for example, join, suspend) set out in the API as needed.

There are several ways of introducing concurrency into an Actor. Every Actor has at least one thread. In practice not every request needs to be executed in one of the Actor's threads. Some are perfectly safe to be concurrently run by any number of external threads. The SST environment provides mechanisms for marking individual methods as Actor methods. Invocations of these methods will be executed only by one of the Actor's own threads. The straightforward way to make a method into an Actor method is to add the following code at the beginning of the method:

sstActorSend builds a message and queues it for the receiver (self) and then waits for a result. Therefore, any Actor methods prefixed by this code will run in one of the receiver's processes.

SST manages the concept of a current Actor (see the sstCurrentActor instance method of ProcessorScheduler). All Smalltalk processes have a defined defaultActor if they are not explicitly part of some other Actor.