Difference between revisions of "Talk:Transactions"

m (Examples)
 
(8 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
Discussion of the feasibility and desirability of implementing transactional concurrency in Eiffel.
 
Discussion of the feasibility and desirability of implementing transactional concurrency in Eiffel.
  
== Examples please ==
+
== Legacy externals ==
 +
Is blocking all threads and executing legacy externals sufficient to ensure correct operation
  
I think we need to see some examples (well, I do for one).
+
Is it possible to check for legacy externals within a transaction at runtime
  
== Examples ==
+
== Implementation performance ==
The main thing to remember is that the proposal states that all features calls are asynchronous.
+
Performance of software transactional memory.
 +
Current implementations of software transactional memory.
  
Transactions are assured with transactional memory, probably implemented as software transactional memory.
+
== Asynchronous features==
----------------
+
Is there a need for synchronous features
Example of transaction:<br/>
+
feature<br/>
+
correct_removal(container: DISPENSER) is<br/>
+
&nbsp;transaction  --  This is a transaction so it is assured to be atomic and isolated<br/>
+
&nbsp;&nbsp;if<br/>
+
&nbsp;&nbsp;&nbsp;not(container.is_empty)<br/>
+
&nbsp;&nbsp;then<br/>
+
&nbsp;&nbsp;&nbsp;container.remove<br/>
+
&nbsp;&nbsp;end<br/>
+
&nbsp;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.
+
== Language keywords ==
-----------------
+
Use a word to define a transaction or a non-transaction
  
feature<br/>
+
== Examples please ==
incorrect_removal(container: DISPENSER) is<br/>
+
 
&nbsp;do<br/>
+
I think we need to see some examples (well, I do for one).
&nbsp;&nbsp;if<br/>
+
&nbsp;&nbsp;&nbsp;not(container.is_empty)<br/>
+
&nbsp;&nbsp;then<br/>
+
&nbsp;&nbsp;&nbsp;container.remove<br/>
+
&nbsp;&nbsp;end<br/>
+
&nbsp;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.
+
== Need for synchronous features ==
----------------
+
  
Example of concurrency:<br/>
+
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).
feature<br/>
+
write_all_files is<br/>
+
&nbsp;do<br/>
+
&nbsp;&nbsp;write_file_1<br/>
+
&nbsp;&nbsp;write_file_2<br/>
+
&nbsp;&nbsp;write_file_3<br/>
+
&nbsp;&nbsp;write_file_4<br/>
+
&nbsp;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.
+
== Posted by Bertrand Meyer on the eiffel_software group ==
----------------
+
  
feature<br/>
+
colinlema wrote:
write_file is<br/>
+
> it seems like SCOOP is
&nbsp;external<br/>
+
> currently at a standstill research-wise.
&nbsp;&nbsp;"operating_system_write"<br/>
+
&nbsp;abort<br/>
+
&nbsp;&nbsp;"operating_system_abort"<br/>
+
&nbsp;commit<br/>
+
&nbsp;&nbsp;"operating_system_commit"<br/>
+
  
This is how transactional features can be mapped on to external function calls that support transactional operations
+
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.
  
feature<br/>
+
-- BM
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/>
+
== Work in progress ==
&nbsp;do<br/>
+
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.
&nbsp;&nbsp;from<br/>
+
&nbsp;&nbsp;until<br/>
+
&nbsp;&nbsp;&nbsp;not (running)<br/>
+
&nbsp;&nbsp;loop --This loop will spawn multiple threads, microthreads, hyperthreads, or whatever the implementation is and runtime chooses, all processing a single item.<br/>
+
&nbsp;&nbsp;&nbsp;process_single_item<br/>
+
&nbsp;&nbsp;end<br/>
+
&nbsp;end<br/>
+
<br/>
+
process_single_item is<br/>
+
&nbsp;local<br/>
+
&nbsp;&nbsp;item: ANY<br/>
+
&nbsp;transaction --Since this is a transaction,  accessing the container is safe even when run concurrently.<br/>
+
&nbsp;&nbsp;if<br/>
+
&nbsp;&nbsp;&nbsp;not source.is_empty<br/>
+
&nbsp;&nbsp;then<br/>
+
&nbsp;&nbsp;&nbsp;item := source.item<br/>
+
&nbsp;&nbsp;&nbsp;source.remove<br/>
+
&nbsp;&nbsp;&nbsp;io.put_string(item.to_string)<br/>
+
&nbsp;&nbsp;&nbsp;destination.put(item)<br/>
+
&nbsp;&nbsp;end<br/>
+
&nbsp;end<br/>
+
<br/>
+

Latest revision as of 07:43, 17 July 2007

Discussion of the feasibility and desirability of implementing transactional concurrency in Eiffel.

Legacy externals

Is blocking all threads and executing legacy externals sufficient to ensure correct operation

Is it possible to check for legacy externals within a transaction at runtime

Implementation performance

Performance of software transactional memory. Current implementations of software transactional memory.

Asynchronous features

Is there a need for synchronous features

Language keywords

Use a word to define a transaction or a non-transaction

Examples please

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).

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

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.