Transactions - Revision history

Clemahieu at 15:40, 17 July 2007

2007-07-17T15:40:57Z

Show changes

Clemahieu: /* Examples */

2007-04-09T19:44:32Z

‎Examples

Juliant at 16:45, 9 April 2007

2007-04-09T16:45:33Z

Clemahieu: /* Examples */

2007-04-06T23:53:14Z

‎Examples

Clemahieu: /* Examples */

2007-04-06T23:52:05Z

‎Examples

Juliant: formatting of examples

2007-04-06T22:55:51Z

formatting of examples

Show changes

Clemahieu: /* Examples */

2007-04-06T21:55:48Z

‎Examples

Clemahieu at 21:55, 6 April 2007

2007-04-06T21:55:13Z

Clemahieu: Examples

2007-04-06T20:38:52Z

Examples

Juliant: added ECMA category

2007-04-06T19:18:00Z

added ECMA category

@@ Line 329: / Line 329: @@
      --This feature would compile since it would be undecidible if 'other' is attached to an instance of C at runtime
      do
-       other.transactional_call(agent legacy_external_feature)
+       other.redefined_call(agent legacy_external_feature)
      end

@@ Line 69: / Line 69: @@
 *Features with preconditions and postconditions can only be called from a feature that is a transaction as a validation constraint.
 *If a transactional feature 'f' wants to call feature 'g' with a precondition 'a', 'f' can check 'a' before calling 'g' and is assured that 'a' will be the same once 'g' is being executed by the transactional nature of 'f'; 'a' will either remain valid or 'f' will be aborted and retried.
-*Postcondition wait semantics as introduced with SCOOP do not need to be used as the compiler or runtime will determine the execution schedule of a program.
+*Precondition wait semantics as introduced with SCOOP do not need to be used as the compiler or runtime will determine the execution schedule of a program.
 *Class invariants determine the consistency of transactions and are checked every time a transaction is committed and after it is aborted

@@ Line 327: / Line 327: @@
    call_transaction_with_agent is
-     --This feature would compile since it would be undecidible if B is attached to an instance of C at runtime
+     --This feature would compile since it would be undecidible if 'other' is attached to an instance of C at runtime
      do
        other.transactional_call(agent legacy_external_feature)

← Older revision		Revision as of 23:52, 6 April 2007
Line 311:		Line 311:

	This is useful for disjoint functionality		This is useful for disjoint functionality
		+
		+
		+	--------------
		+	Example of need for runtime checks on agents in systems that allow legacy external features. Once legacy external features are not used this check will not be necessary.
		+
		+	<e>
		+
		+	class A
		+	feature
		+	other: B
		+	legacy_external_feature is
		+	external
		+	"..."
		+	end
		+
		+	call_transaction_with_agent is
		+	--This feature would compile since it would be undecidible if B is attached to an instance of C at runtime
		+	do
		+	other.transactional_call(agent legacy_external_feature)
		+	end
		+
		+	a_transaction is
		+	--This feature is a compile time error as a validity constraint
		+	transaction
		+	legacy_external_feature
		+	end
		+
		+	end
		+
		+	deferred class B
		+	feature
		+	redefined_call(the_agent: PROCEDURE[TUPLE[]]) is
		+	--A reason to allow deferred features to be redefined
		+	--to a transaction or not is for syntax simplicity
		+	--and because the only time it matters is when building
		+	--new transactions on top of legacy code
		+	deferred
		+	end
		+	end
		+
		+	class C
		+	inherit B
		+	feature
		+	redefined_call(the_agent: PROCEDURE[TUPLE[]]) is
		+	transaction
		+	io.put_string("Line 1")
		+
		+	--This call is a runtime exception. The probability of this happening
		+	--is low because people building transactional code should be looking
		+	--at replacing legacy external features with transactional externals
		+	--or some other transaction abstraction over externals
		+	the_agent.call
		+
		+	io.put_string("Line 2")
		+	</e>

@@ Line 240: / Line 240: @@
 Difference between a transaction and non-transaction
-feature
+feature<br/>
-write_things_1 is
+write_things_1 is<br/>
-transaction
+transaction<br/>
-io.put_string("Line one")
+io.put_string("Line one")<br/>
-io.put_new_line
+io.put_new_line<br/>
-io.put_string("Line two")
+io.put_string("Line two")<br/>
-io.put_new_line
+io.put_new_line<br/>
-end
+end<br/>
 This feature is assured that line two will appear right after line one.
-write_things_2 is
+write_things_2 is<br/>
-do
+do<br/>
-io.put_string("Line one")
+io.put_string("Line one")<br/>
-io.put_new_line
+io.put_new_line<br/>
-io.put_string("Line two")
+io.put_string("Line two")<br/>
-io.put_new_line
+io.put_new_line<br/>
-end
+end<br/>
 This feature is not assured that line two will appear after line one. Any number of lines could have been inserted between each by other paths of execution printing to the screen.
 This is useful for disjoint functionality

← Older revision		Revision as of 21:55, 6 April 2007
Line 237:		Line 237:
	...<br/>		...<br/>
	end<br/>		end<br/>
		+	------------------
		+	Difference between a transaction and non-transaction
		+
		+	feature
		+	write_things_1 is
		+	transaction
		+	io.put_string("Line one")
		+	io.put_new_line
		+	io.put_string("Line two")
		+	io.put_new_line
		+	end
		+
		+	This feature is assured that line two will appear right after line one.
		+
		+	write_things_2 is
		+	do
		+	io.put_string("Line one")
		+	io.put_new_line
		+	io.put_string("Line two")
		+	io.put_new_line
		+	end
		+
		+	This feature is not assured that line two will appear after line one. Any number of lines could have been inserted between each by other paths of execution printing to the screen.
		+
		+	This is useful for disjoint functionality

← Older revision		Revision as of 20:38, 6 April 2007
Line 124:		Line 124:

	*It might be better to use a keyword to define a feature as non-transactional instead of using a keyword to define a feature as transactional.		*It might be better to use a keyword to define a feature as non-transactional instead of using a keyword to define a feature as transactional.
		+
		+	== Examples ==
		+	The main thing to remember is that the proposal states that all features calls are asynchronous.
		+
		+	Transactions are assured with transactional memory, probably implemented as software transactional memory.
		+	----------------
		+	Example of transaction:<br/>
		+	feature<br/>
		+	correct_removal(container: DISPENSER) is<br/>
		+	transaction -- This is a transaction so it is assured to be atomic and isolated<br/>
		+	if<br/>
		+	not(container.is_empty)<br/>
		+	then<br/>
		+	container.remove<br/>
		+	end<br/>
		+	end<br/>
		+
		+	This feature is assured to be correct because is is isolated and atomic with respect to the system. If the container has been modified between the call to is_empty and remove, the feature would be aborted and retried.
		+	-----------------
		+
		+	feature<br/>
		+	incorrect_removal(container: DISPENSER) is<br/>
		+	do<br/>
		+	if<br/>
		+	not(container.is_empty)<br/>
		+	then<br/>
		+	container.remove<br/>
		+	end<br/>
		+	end<br/>
		+
		+	This is the standard example of concurrency issues with preconditions. The container can change between the call to is_empty and remove. Using transactions avoids this.
		+	----------------
		+
		+	Example of concurrency:<br/>
		+	feature<br/>
		+	write_all_files is<br/>
		+	do<br/>
		+	write_file_1<br/>
		+	write_file_2<br/>
		+	write_file_3<br/>
		+	write_file_4<br/>
		+	end<br/>
		+
		+	Since all feature calls would be asynchronous, the four write_file features could be executed in parallel if the runtime decides to do so. This is not a transaction so isolation across these calls is not assured.
		+	----------------
		+
		+	feature<br/>
		+	write_file is<br/>
		+	external<br/>
		+	"operating_system_write"<br/>
		+	abort<br/>
		+	"operating_system_abort"<br/>
		+	commit<br/>
		+	"operating_system_commit"<br/>
		+
		+	This is how transactional features can be mapped on to external function calls that support transactional operations
		+	----------------
		+
		+	feature<br/>
		+	source: DISPENSER[ANY] --Where items are taken from<br/>
		+	destination: DISPENSER[ANY] -- where items are put after processing<br/>
		+	running: BOOLEAN -- Flag to stop processing<br/>
		+
		+	consumer is<br/>
		+	do<br/>
		+	from<br/>
		+	until<br/>
		+	not (running)<br/>
		+	loop --This loop will spawn multiple threads, microthreads, hyperthreads, or whatever the implementation is and runtime chooses, all processing a single item.<br/>
		+	process_single_item<br/>
		+	end<br/>
		+	end<br/>
		+	<br/>
		+	process_single_item is<br/>
		+	local<br/>
		+	item: ANY<br/>
		+	transaction --Since this is a transaction, accessing the container is safe even when run concurrently.<br/>
		+	if<br/>
		+	not source.is_empty<br/>
		+	then<br/>
		+	item := source.item<br/>
		+	source.remove<br/>
		+	io.put_string(item.to_string)<br/>
		+	destination.put(item)<br/>
		+	end<br/>
		+	end<br/>
		+	<br/>
		+	---------------
		+	Legacy externals example
		+
		+	feature<br/>
		+	use_legacy_external(item: LEGACY_ITEM) is<br/>
		+	do<br/>
		+	print_item(item)<br/>
		+	log_item(item)<br/>
		+	--At this point the runtime will block until print_item and log_item have both committed, it will ensure nothing is running in the system and then run the external item serially. This is the non-concurrent way to ensure something executes as a transaction, isolated and atomic.<br/>
		+	use_item(item)<br/>
		+	end<br/>
		+	<br/>
		+	use_item(item: LEGACY_ITEM) is<br/>
		+	external<br/>
		+	"..."<br/>
		+	end<br/>
		+	<br/>
		+	print_item(item: LEGACY_ITEM) is<br/>
		+	do<br/>
		+	...<br/>
		+	end<br/>
		+	<br/>
		+	log_item(item: LEGACY_ITEM) is<br/>
		+	do<br/>
		+	...<br/>
		+	end<br/>

← Older revision		Revision as of 19:18, 6 April 2007
Line 1:		Line 1:
		+	[[Category:ECMA]]
		+
	This is something I've been looking at for the last day or so. I was really looking for a concurrency solution that solves issues of concurrency from a language standpoint and it seems like SCOOP is currently at a standstill research-wise.		This is something I've been looking at for the last day or so. I was really looking for a concurrency solution that solves issues of concurrency from a language standpoint and it seems like SCOOP is currently at a standstill research-wise.