SCOOP - Revision history

Hzwakenberg: Link to SCOOP lecture no longer exists, hence removed here

2021-12-30T11:18:38Z

Link to SCOOP lecture no longer exists, hence removed here

← Older revision		Revision as of 13:18, 30 December 2021
Line 10:		Line 10:
	* http://se.inf.ethz.ch/people/nienaltowski/papers/oopsla04.pdf		* http://se.inf.ethz.ch/people/nienaltowski/papers/oopsla04.pdf
	* http://se.inf.ethz.ch/people/nienaltowski/papers/scoop_easy_draft.pdf		* http://se.inf.ethz.ch/people/nienaltowski/papers/scoop_easy_draft.pdf
−	* http://se.ethz.ch/teaching/2009-S/0268/lectures/lecture%207.pptx

	They are interesting. They truly are. And they try to solve a real problem: the rules defined by B.M. in OOSC2 are not quite as sound as we would like. I'm glad they saw it at last, by really working on SCOOP.		They are interesting. They truly are. And they try to solve a real problem: the rules defined by B.M. in OOSC2 are not quite as sound as we would like. I'm glad they saw it at last, by really working on SCOOP.

Hzwakenberg: /* The problem */

2018-09-09T12:49:47Z

The problem

← Older revision		Revision as of 14:49, 9 September 2018
Line 20:		Line 20:
	How does one pass a STRING to a separate STRING, in order to concatenate it?? One cannot.		How does one pass a STRING to a separate STRING, in order to concatenate it?? One cannot.

−	I think their "separate" keyword is a virus. It ~~spreads~~ to any class that may deal with separate reference.	+	I think their "separate" keyword is a virus. It going to spread to any class that may deal with separate reference.

	But there are good things in those papers, esp. concerning lock passing (although I need to read again when fully awake).		But there are good things in those papers, esp. concerning lock passing (although I need to read again when fully awake).

Hzwakenberg at 22:02, 12 June 2016

2016-06-12T22:02:36Z

← Older revision		Revision as of 00:02, 13 June 2016
Line 30:		Line 30:
	== Separate is a class property ==		== Separate is a class property ==

−	Like '''deferred''' which in ~~LibertyEiffel~~ can only be a property of a class (not of a random entity), '''separate''' is also a property of a class.	+	Like '''deferred''' which in Liberty Eiffel can only be a property of a class (not of a random entity), '''separate''' is also a property of a class.

	In other words, to keep it simple, a class (and therefore John Doe who programs it) is "aware" of its separateness status.		In other words, to keep it simple, a class (and therefore John Doe who programs it) is "aware" of its separateness status.

Hzwakenberg: /* once */

2016-03-05T11:48:17Z

once

← Older revision		Revision as of 13:48, 5 March 2016
Line 70:		Line 70:
	* if the once function returns a non-separate object, then it is evaluated '''once per calling processor''' and the returned reference depends on the calling processor.		* if the once function returns a non-separate object, then it is evaluated '''once per calling processor''' and the returned reference depends on the calling processor.

−	Note that this case definition degrades gracefully for non-SCOOP systems, which are merely systems having one processor.	+	Note that this case definition degrades gracefully for non-SCOOP systems, which are merely systems having or using one processor.

	== Standard input/output ==		== Standard input/output ==

Hzwakenberg: /* Allow passing reference objects */

2016-03-05T11:43:59Z

Allow passing reference objects

← Older revision		Revision as of 13:43, 5 March 2016
Line 42:		Line 42:
	* This forces a "pass-by-copy" semantics on all non-separate objects<ref>Not "pass-by-value". Eiffel is strictly pass-by-value anyway since you cannot write the <TT>swap(a, b)</TT> method in Eiffel. Referenced objects are passed by their reference value. To be precise (and quite pedantic), in the case of separate objects, the passed value is the reference of a new object belonging to the good processor ("imported").</ref>.		* This forces a "pass-by-copy" semantics on all non-separate objects<ref>Not "pass-by-value". Eiffel is strictly pass-by-value anyway since you cannot write the <TT>swap(a, b)</TT> method in Eiffel. Referenced objects are passed by their reference value. To be precise (and quite pedantic), in the case of separate objects, the passed value is the reference of a new object belonging to the good processor ("imported").</ref>.
	* Two distinct separate objects, even if they belong to the same class, have distinct processors.		* Two distinct separate objects, even if they belong to the same class, have distinct processors.
−	* In other words, the only separate objects having the same processor ~~than~~ '''Current''', are '''Current''' and its non-separate references.	+	* In other words, the only separate objects having the same processor as '''Current''', are '''Current''' and its non-separate references.

	== The rules ==		== The rules ==

Hzwakenberg: /* Separate is a class property */

2016-03-05T11:42:51Z

Separate is a class property

← Older revision		Revision as of 13:42, 5 March 2016
Line 30:		Line 30:
	== Separate is a class property ==		== Separate is a class property ==

−	Like '''deferred''' which in ~~SmartEiffel (and therefore in Liberty)~~ can only be a property of a class (not of a random entity), '''separate''' is also a property of a class.	+	Like '''deferred''' which in LibertyEiffel can only be a property of a class (not of a random entity), '''separate''' is also a property of a class.

	In other words, to keep it simple, a class (and therefore John Doe who programs it) is "aware" of its separateness status.		In other words, to keep it simple, a class (and therefore John Doe who programs it) is "aware" of its separateness status.

Hzwakenberg: /* The problem */

2016-03-05T11:41:17Z

The problem

← Older revision		Revision as of 13:41, 5 March 2016
Line 5:		Line 5:
	= The problem =		= The problem =

−	And as always in the ECMA Eiffel world, things get complicated. See ~~those~~ articles:	+	And as always in the ECMA Eiffel world, things get complicated. See these articles:
	* http://se.ethz.ch/people/nienaltowski/papers/contracts_for_concurrency.pdf		* http://se.ethz.ch/people/nienaltowski/papers/contracts_for_concurrency.pdf
	* http://se.ethz.ch/people/nienaltowski/papers/flexible_locking_in_scoop.pdf		* http://se.ethz.ch/people/nienaltowski/papers/flexible_locking_in_scoop.pdf

Ramack: import from github wiki

2013-03-23T23:07:21Z

import from github wiki

New page

SCOOP means '''Simple Concurrent Object Oriented Programming'''.

The keyword here, is '''simple'''. As always in Eiffel.

= The problem =

And as always in the ECMA Eiffel world, things get complicated. See those articles:
* http://se.ethz.ch/people/nienaltowski/papers/contracts_for_concurrency.pdf
* http://se.ethz.ch/people/nienaltowski/papers/flexible_locking_in_scoop.pdf
* http://se.inf.ethz.ch/people/nienaltowski/papers/oopsla04.pdf
* http://se.inf.ethz.ch/people/nienaltowski/papers/scoop_easy_draft.pdf
* http://se.ethz.ch/teaching/2009-S/0268/lectures/lecture%207.pptx

They are interesting. They truly are. And they try to solve a real problem: the rules defined by B.M. in OOSC2 are not quite as sound as we would like. I'm glad they saw it at last, by really working on SCOOP.

But I do not agree with their solution. It's complex. I'm curious to see the error messages they will display to the John Doe programmer who wants a little bit of concurrency (well, ''I am'' John Doe).
Simple? Where is it??

And it does not allow to pass a non-separate object to a separate target. Yes, I know about the "traitor" concept; but the solution is not simple since any random library must be "prepared" to accept separate object.
How does one pass a STRING to a separate STRING, in order to concatenate it?? One cannot.

I think their "separate" keyword is a virus. It spreads to any class that may deal with separate reference.

But there are good things in those papers, esp. concerning lock passing (although I need to read again when fully awake).

= Liberty's solution (this is still science fiction) =

There is another way: keep it SIMPLE. Really.

== Separate is a class property ==

Like '''deferred''' which in SmartEiffel (and therefore in Liberty) can only be a property of a class (not of a random entity), '''separate''' is also a property of a class.

In other words, to keep it simple, a class (and therefore John Doe who programs it) is "aware" of its separateness status.
Furthermore, this rule helps to circumscribe the concurrency management to as few classes as possible.

== Allow passing reference objects ==

Yes, but not traitors. Reference objects must be deeply copied in the target's processor. Ditto for expanded objects containing non-separate references.

'''Notes:'''
* This forces a "pass-by-copy" semantics on all non-separate objects<ref>Not "pass-by-value". Eiffel is strictly pass-by-value anyway since you cannot write the <TT>swap(a, b)</TT> method in Eiffel. Referenced objects are passed by their reference value. To be precise (and quite pedantic), in the case of separate objects, the passed value is the reference of a new object belonging to the good processor ("imported").</ref>.
* Two distinct separate objects, even if they belong to the same class, have distinct processors.
* In other words, the only separate objects having the same processor than '''Current''', are '''Current''' and its non-separate references.

== The rules ==
'''Definition:''' an imported object (from an original object) is:
* a reference or expanded object that belongs to the target's processor, with each of its attribute being also imported from the original object's corresponding attribute (recursively).
* a separate object belonging to another processor stays attached to that processor.
* Void stays Void.

Rules:
# A class may be either '''expanded''' or '''separate''', but not both.
# If a formal argument of a routine defined in a separate class is...
#* separate, then the actual argument's value will be the reference of the original object, which is locked by the routine until its completion.
#* ''not'' separate, then the actual argument's value will be ''the reference of an object imported'' into the target's processor (see rule 4 exception).
# If the result of a routine defined in a separate class is...
#* separate, then the returned object's value will be passed Result's reference.
#* ''not'' separate, then the returned object's value will be ''the reference of Result imported'' back into the caller's processor (see rule 4 exception).
# If the caller's and target's processors are the same <ref>In a separate class the target's and caller's processors are the same only if the target of a routine call is either '''Current''' or a non-separate object.</ref> then the objects are ''not'' imported and the passed value is the original reference.

'''Conformance rules:'''
* if a separate class <TT>TS</TT> inherits from a non-separate class <TT>T</TT>, then any <TT>t: T</TT> may be attached to a <TT>ts: TS</TT> entity (but not the opposite)
* a class T cannot inherit from, or insert, any separate class.

== once ==

The semantics of once functions is slightly changed:
* if the once function returns a separate object, then it is evaluated once in the life of the entire program and the same separate entity reference is returned at each call
* if the once function returns a non-separate object, then it is evaluated '''once per calling processor''' and the returned reference depends on the calling processor.

Note that this case definition degrades gracefully for non-SCOOP systems, which are merely systems having one processor.

== Standard input/output ==

No special provision for <TT>std_input</TT>, <TT>std_output</TT>, <TT>std_error</TT>, and <TT>io</TT>. The classes are not separate, hence the objects are evaluated in each processor.

As a consequence, the behavior of those entities depends on the underlying operating system.

<br><hr width='20%'>

<references/>