|
|
| (7 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/>
| |
| 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.
| | == Language keywords == |
| -----------------
| | Use a word to define a transaction or a non-transaction |
|
| |
|
| feature<br/>
| | == Examples please == |
| 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.
| | I think we need to see some examples (well, I do for one). |
| ----------------
| |
|
| |
|
| Example of concurrency:<br/>
| | == Need for synchronous features == |
| 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.
| | 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/>
| | == Posted by Bertrand Meyer on the eiffel_software group == |
| 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
| | colinlema wrote: |
| ---------------- | | > it seems like SCOOP is |
| | > currently at a standstill research-wise. |
|
| |
|
| feature<br/>
| | Where did you get this impression? The project is in full swing; Piotr |
| source: DISPENSER[ANY] --Where items are taken from<br/>
| | Nienaltowski's thesis, defended in February, made considerable |
| destination: DISPENSER[ANY] -- where items are put after processing<br/>
| | improvements to SCOOP; it will be on the Web soon. There's a whole set |
| running: BOOLEAN -- Flag to stop processing<br/>
| | of recent publications by him and other people. The implementation |
| | currently works through a preprocessor but will be integrated into the |
| | compiler. |
|
| |
|
| consumer is<br/>
| | -- BM |
| 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/>
| | == Work in progress == |
| use_legacy_external(item: LEGACY_ITEM) is<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. |
| 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/>
| |
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.