Difference between revisions of "Talk:Transactions"
(A couple examples.) |
(→Examples please) |
||
| Line 10: | Line 10: | ||
Example of transaction: | Example of transaction: | ||
| − | feature | + | feature<br/> |
| − | correct_removal(container: DISPENSER) is | + | correct_removal(container: DISPENSER) is<br/> |
| − | transaction -- This is a transaction so it is assured to be atomic and isolated | + | transaction -- This is a transaction so it is assured to be atomic and isolated<br/> |
| − | if | + | if<br/> |
| − | not(container.is_empty) | + | not(container.is_empty)<br/> |
| − | then | + | then<br/> |
| − | container.remove | + | container.remove<br/> |
| − | end | + | end<br/> |
| − | end | + | 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. | 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 | + | feature<br/> |
| − | incorrect_removal(container: DISPENSER) is | + | incorrect_removal(container: DISPENSER) is<br/> |
| − | do | + | do<br/> |
| − | if | + | if<br/> |
| − | not(container.is_empty) | + | not(container.is_empty)<br/> |
| − | then | + | then<br/> |
| − | container.remove | + | container.remove<br/> |
| − | end | + | end<br/> |
| − | end | + | 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. | 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: | Example of concurrency: | ||
| − | feature | + | feature<br/> |
| − | write_all_files is | + | write_all_files is<br/> |
| − | do | + | do<br/> |
| − | write_file_1 | + | write_file_1<br/> |
| − | write_file_2 | + | write_file_2<br/> |
| − | write_file_3 | + | write_file_3<br/> |
| − | write_file_4 | + | write_file_4<br/> |
| − | end | + | 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. | 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. | ||
Revision as of 10:33, 6 April 2007
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).
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:
feature
correct_removal(container: DISPENSER) is
transaction -- This is a transaction so it is assured to be atomic and isolated
if
not(container.is_empty)
then
container.remove
end
end
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
incorrect_removal(container: DISPENSER) is
do
if
not(container.is_empty)
then
container.remove
end
end
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:
feature
write_all_files is
do
write_file_1
write_file_2
write_file_3
write_file_4
end
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.
