Server Smalltalk Guide

Programming with Actors

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:

self  Processor sstCurrentActor ifTrue: [^self sstActorSend].

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.


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]