Difference between revisions of "Talk:Transactions"
Colin-adams (Talk | contribs) (Examples please) |
|||
| (16 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 == | ||
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). | ||
| + | |||
| + | == 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. | ||
Latest revision as of 06:43, 17 July 2007
Discussion of the feasibility and desirability of implementing transactional concurrency in Eiffel.
Contents
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.
