A Formal Reference for SCOOP - Empirical Software Engineering and Verification - page 108

Processors. A processor is an autonomous thread of control capable of executing fea-
tures on objects. Each processor is responsible for a set of objects. As such a processor
is called the handler of its associated objects. Each object is assigned to exactly one pro-
cessor that is the authority of feature executions on this object. If a processor q wants
to call a feature on an object handled by a different processor p ,then q needs to send
a feature request to processor p . This is where the request queue of processor p comes
into place. The request queue keeps track of features to be executed on behalf of other
processors. Processor q can add a request to this queue and processor p will execute the
request as soon as it executed all previous requests in the request queue. Processor p
uses its call stack to execute the feature request at the beginning of the request queue.
The call stack is responsible for the order of feature executions on the same processor.
In a situation of a non-separate call, the call stack ensures that the calling feature exe-
cution resumes once the called feature execution terminated. The interaction between
the call stack and the request queue is best described with the following loop through
which each processor goes:
1. Idle wait. If both the call stack and the request queue are empty, then wait for new
requests to be enqueued.
2. Request scheduling. If the call stack is empty but the request queue is not empty,
then dequeue an item and push it onto the call stack.
3. Request processing. If there is an item on the call stack, then pop the item from the
call stack and process it. If the item is a feature request, then apply the feature. If
the item is an operation, then execute the operation.
For each processor there is a request queue lock and a call stack lock . A lock on the
request queue grants permission to add a feature request to the end of the request queue.
A lock on the call stack grants permission to add a feature request to the top of the call
stack. Before processor q can add a request to p 's request queue, it must have a lock
on this request queue. Otherwise another processor could intervene. Once processor q
is done with the request queue of processor p it can add an unlock operation to the end
of the request queue. This makes sure that the request queue lock of p will be released
after all the previous feature requests have been executed. Similarly, processor p must
have a lock on its call stack to add features to its call stack. Initially, each processor has
a lock on its own call stack and its request queue is not locked.
Processor q could also make a synchronous call to p .However q might be in posses-
sion of some locks that are necessary for the execution of the resulting feature request
on p . In such a situation, q is waiting for the synchronous call to terminate and p is wait-
ing for locks to be available. According to the conditions given by Coffman et al. [8] a
deadlock occurred. This can be avoided if q temporarily passes its locks to the p .This
allows p to finish the execution and hence q can continue.
Clarification 1 (Request queue locks and call stack locks). The notion of request queue
locks and call stack locks was not present in Nienaltowski's [25] definition of SCOOP.
He defines one lock for each processor. A lock on a processor means exclusive access to
the whole processor. This lock model is not sufficient to describe SCOOP. In particular,
this lock model creates a contradiction with respect to separate callbacks. A separate
callback is a feature call in which processor q made a direct or indirect call to processor