Talk:Transactions - Revision history

Clemahieu at 15:43, 17 July 2007

2007-07-17T15:43:23Z

Clemahieu at 15:42, 17 July 2007

2007-07-17T15:42:24Z

Clemahieu: Posted by Bertrand Meyer on the eiffel_software group

2007-04-11T14:35:42Z

Posted by Bertrand Meyer on the eiffel_software group

Colin-adams: Need for synchronous features

2007-04-09T18:10:17Z

Need for synchronous features

Clemahieu: /* Asynchronous functions */

2007-04-09T15:54:04Z

‎Asynchronous functions

Clemahieu at 15:53, 9 April 2007

2007-04-09T15:53:48Z

Clemahieu at 15:52, 9 April 2007

2007-04-09T15:52:22Z

Clemahieu at 20:38, 6 April 2007

2007-04-06T20:38:30Z

Clemahieu: External example

2007-04-06T20:12:52Z

External example

Clemahieu: /* Examples */

2007-04-06T19:52:39Z

‎Examples

← Older revision		Revision as of 15:43, 17 July 2007
Line 39:		Line 39:
	-- BM		-- BM

		+	== Work in progress ==
	I'm still working on this page occasionally. I still think transactions are a good idea. I'm not a compiler writer, however, so I probably haven't covered all the bases.		I'm still working on this page occasionally. I still think transactions are a good idea. I'm not a compiler writer, however, so I probably haven't covered all the bases.

← Older revision		Revision as of 15:42, 17 July 2007
Line 38:		Line 38:

	-- BM		-- BM
		+
		+	I'm still working on this page occasionally. I still think transactions are a good idea. I'm not a compiler writer, however, so I probably haven't covered all the bases.

← Older revision		Revision as of 14:35, 11 April 2007
Line 23:		Line 23:

	I believe the proposal is that the complier should be able to infer all necessary synchronization (and I presume the only keyword will assume importance here).		I believe the proposal is that the complier should be able to infer all necessary synchronization (and I presume the only keyword will assume importance here).
		+
		+	== Posted by Bertrand Meyer on the eiffel_software group ==
		+
		+	colinlema wrote:
		+	> it seems like SCOOP is
		+	> currently at a standstill research-wise.
		+
		+	Where did you get this impression? The project is in full swing; Piotr
		+	Nienaltowski's thesis, defended in February, made considerable
		+	improvements to SCOOP; it will be on the Web soon. There's a whole set
		+	of recent publications by him and other people. The implementation
		+	currently works through a preprocessor but will be integrated into the
		+	compiler.
		+
		+	-- BM

← Older revision		Revision as of 18:10, 9 April 2007
Line 19:		Line 19:

	I think we need to see some examples (well, I do for one).		I think we need to see some examples (well, I do for one).
		+
		+	== Need for synchronous features ==
		+
		+	I believe the proposal is that the complier should be able to infer all necessary synchronization (and I presume the only keyword will assume importance here).

@@ Line 10: / Line 10: @@
 Current implementations of software transactional memory.
-== Asynchronous functions ==
+== Asynchronous features==
-Is there a need for synchronous functions
+Is there a need for synchronous features
 == Language keywords ==

@@ Line 1: / Line 1: @@
 Discussion of the feasibility and desirability of implementing transactional concurrency in Eiffel.
 == Examples please ==
 I think we need to see some examples (well, I do for one).

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

	I think we need to see some examples (well, I do for one).		I think we need to see some examples (well, I do for one).
−
−	~~== 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 20:12, 6 April 2007
Line 91:		Line 91:
	end<br/>		end<br/>
	<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/>

@@ Line 81: / Line 81: @@
 &nbsp;&nbsp;item: ANY<br/>
 &nbsp;transaction --Since this is a transaction,  accessing the container is safe even when run concurrently.<br/>
-&nbsp;&nbsp;item := source.item<br/>
+&nbsp;&nbsp;if<br/>
-&nbsp;&nbsp;source.remove<br/>
+&nbsp;&nbsp;&nbsp;not source.is_empty<br/>
-&nbsp;&nbsp;io.put_string(item.to_string)<br/>
+&nbsp;&nbsp;then<br/>
-&nbsp;&nbsp;destination.put(item)<br/>
+&nbsp;&nbsp;&nbsp;item := source.item<br/>
 &nbsp;end<br/>
 <br/>