eiffel-org/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-implementation.wiki

[[Property:title|SCOOP implementation]]
[[Property:weight|2]]
[[Property:uuid|eeb07907-e036-f3d6-5297-a7c44cfd1900]]
The implementation of SCOOP within EiffelStudio varies from the definition as it has been presented in publications during the model's evolution. 

Some of the differences stem from the reality that SCOOP systems could be optimized for performance, including maximizing concurrency. For example, even though the SCOOP rules state that a separate call to a query is synchronous, i. e., the calling processor waits until the query completes before proceeding, if a static analysis can show that the wait is not necessary to the proper functioning of the remainder of the calling routine, then the call to the query can be done asynchronously. 

In other ways, particularly for early versions, the EiffelStudio implementation may not cover all the goals of SCOOP as stated in the various publications. Certain elements that are defined in the SCOOP descriptions may not yet be present, or only partially implemented in the EiffelStudio implementation.  

The differences between the EiffelStudio implementation of SCOOP and current and previous definitions of the SCOOP model are shown below.


=Known limitations=


==Supported concurrency mechanisms==

Although the SCOOP model can support virtually any underlying concurrency mechanism, the initial SCOOP implementation in EiffelStudio version 6.8 supports only one executable, using multiple process threads as SCOOP [[Concurrent Eiffel with SCOOP#Processors|processors]].


==Maximum number of SCOOP processors==

In the initial release, the allowable maximum number of SCOOP processors per system is 1024.


==Separate anchored types==

Applicable prior to revision number 86657: 

Separate status for anchored types is not supported properly. So declarations of the form:

<code>
            my_entity: separate like my_query
</code>
 
and

<code>
            my_entity: separate like Current
</code>

should be used only if you are using revision 86657 or later. 

Also, if you use an anchored declaration such as:

<code>
            my_entity: like my_query
</code>

and the type of <code>my_query</code> is <code>separate</code>, you should make sure you are using revision 86657 or later.


==Agents targeted to objects of separate types==

In version 6.8, agents targeted on separate objects are not supported.


=Workarounds=

The first implementation of SCOOP, some things that we do commonly in sequential Eiffel become less fluid in the presence of SCOOP. Although not strictly limitations in the implementation of SCOOP principles, in order to make SCOOP programming easier, these are areas that should be improved in future releases. In the meantime, there are workarounds for some of these situations.


==Printing a <code>separate STRING</code> ==

Suppose you have declared a class attribute of type <code>separate STRING</code>:

<code>
    my_separate_string: separate STRING = "Hello Eiffel World!"
</code>

and you want to output that string using <code>io.put_string</code>. The solution you might use from sequential Eiffel would be:

<code>
            io.put_string (my_separate_string)
</code>

But the statement above results in a compile error because the argument type (<code>separate STRING</code>) is not compatible with the type (<code>STRING</code>) that <code>put_string</code> is expecting.

Possible workarounds are to produce a non-separate version of the string which would be printable, or to print the string character-by-character. Both involve looping through the string. 

To construct equivalent objects of type <code>STRING</code> from those of type <code>separate STRING</code>, you could write a function:

<code>
    non_separate_string (a_sep_str: separate STRING): STRING
            -- Non-separate copy of `a_sep_str'
        local
            i: INTEGER
        do
            create Result.make_empty
            from
                i := 1
            until
                i > a_sep_str.count
            loop
                Result.append_character (a_sep_str [i])
                i := i + 1
            end
        end
</code>

Then you could print <code>my_separate_string</code> this way:

<code>
            io.put_string (non_separate_string (my_separate_string))
</code>

The other alternate is to create a procedure that will print an object of type <code>separate STRING</code>:

<code>
    print_separate_string (a_sep_str: separate STRING)
            -- Print `a_sep_str' on standard output.
        local
            i: INTEGER
        do
            from
                i := 1
            until
                i > a_sep_str.count
            loop
                io.put_character (a_sep_str [i])
                i := i + 1
            end
        end
</code>

Then you could use that procedure to output <code>my_separate_string</code>:

<code>
            print_separate_string (my_separate_string)
</code>


=Implementation dependent behavior=


==The Wait Rule==

The [[Concurrent Eiffel with SCOOP#Access to shared resources|Wait Rule]] says: ''A routine call with separate arguments will execute when all corresponding processors are available and hold them exclusively for the duration of the routine.''

In the EiffelStudio implementation, a routine will not necessarily wait for all processors associated with its separate arguments to be available before it ''begins'' execution. The waiting on processors occurs in a "lazy" manner. Execution will only wait on the availability of one of the processors when it actually needs to use the argument associated with that processor. This means that if there are several instructions ahead of the first instruction that references a separate argument, then those several instructions will be executed immediately. Only at the point at which the separate argument's processor is needed will the routine pause and wait for the availability of the processor.