Difference between revisions of "Talk:Transactions"

(→‎Examples please)
 
(14 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.
 +
 +
== 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 ==
 
== Examples please ==
Line 5: Line 20:
 
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).
  
−
The main thing to remember is that the proposal states that all features calls are asynchronous.
+
== Need for synchronous features ==
−
 
+
−
Transactions are assured with transactional memory, probably implemented as software transactional memory.
+
  
−
Example of transaction:
+
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/>
+
−
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.
+
== Posted by Bertrand Meyer on the eiffel_software group ==
  
−
feature<br/>
+
colinlema wrote:
−
incorrect_removal(container: DISPENSER) is<br/>
+
> it seems like SCOOP is
−
&nbsp;do<br/>
+
> currently at a standstill research-wise.
−
&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.
+
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.
  
−
Example of concurrency:
+
-- BM
−
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.
+
== 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.

Latest revision as of 06: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.

Retrieved from "https://dev.eiffel.com/index.php?title=Talk:Transactions&oldid=9032"