Mixing SCOOP with EiffelThread

by Ian King (modified: 2013 Aug 05)

Although SCOOP brings simplified concurrency to the table, there may be some circumstances where the use of the EiffelThread library is needed.

    <li> Use of legacy code, such as the EiffelProcess library <li> More refined concurrency using underlying Operating System synchronization primitives, ie: non-binary semaphores
This brings certain complications because an Eiffel Thread is not designed to handle calls on objects that are technically separate to the thread itself, but are locally typed. The following example demonstrates this. create worker_thread.make (agent routine_from_separate_processor) worker_thread.launch

Here a locally typed worker_thread object is instantiated from a scoop processor and passed an agent that is created from the processor itself. When the thread goes to launch and execute the worker agent, the thread calls the agent as if it was created by the thread. This can lead to problems in the case where the routine represented by the agent has calls on separate objects. Previous versions of the SCOOP run-time would treat all objects created from a processor as always separate to a thread and therefore leading to issues further down the line as only SCOOP processors can handle separate calls. In order to solve/workaround this, an EiffelThread has to be thought of solely as a worker thread for the SCOOP processor that creates the initial thread object (`worker_thread' in the example), so any calls on objects created from the parent processor are treated as local.

This means that the use of threads with SCOOP is restricted to the processor that launches them:

    <li>All calls on objects that are created by the parent processor are treated as non-separate to match the typing <li>A thread cannot make any calls on separate objects

Currently the run-time has been updated to handle local calls on parent processor owned objects, but as of writing there is no restriction on logging calls on separate types from an Eiffel Thread but a run-time check will be generated in the future.