TransactionalMemory
From APIDesign
| (5 intermediate revisions not shown.) | |||
| Line 1: | Line 1: | ||
| - | [[TransactionalMemory]] is an attempt to bring the power of databases to general purpose programming languages. | + | [[TransactionalMemory]] is an attempt to bring the power of databases to general purpose programming languages. Read below to learn how such an effort failed, but also how to take the ''best of it''! |
| - | + | == Overview & History (of the failure) == | |
| - | A more meta-level thought: Joe's [http:// | + | [[wikipedia:Transactional Memory]] should be the ultimate source of information, however it seems that much better understanding of [[TransactionalMemory]] can be obtained by reading follwing [http://joeduffyblog.com/2010/01/03/a-brief-retrospective-on-transactional-memory/ practitioner's report]. Joe Duffy's text is worth reading - it shows why weak [[TransactionalMemory]] cannot work. In the process of showing that it describes the gory details that remain unnoticed in the general overview at [[wikipedia:Transactional Memory]]. |
| + | |||
| + | As far as I can tell Joe's [http://joeduffyblog.com/2010/01/03/a-brief-retrospective-on-transactional-memory/ write up] is one of the best texts on internet I have read in months. It is deep, detailed, informative, entertaining and contains pieces of wisdom you don't want to miss. Like the ''"these kinds of moments make me a believer in formal computer science"'' acknowledgement. | ||
| + | |||
| + | == [[TransactionalDataStructure]] == | ||
| + | |||
| + | Looking back at Joe's fifteen years old post, I have to nod: The [[TransactionalMemory]] buzz is over. I haven't hard about [[TransactionalMemory]], but that ''doesn't mean the whole idea was wrong''! Recently (at [[GeeCON]] 2025) I heard a presentation about [[LockFreeAlgorithm]]s. The name didn't ring any bell in my head, but after a while [[I]] realized it is actually talking about data structures that resemble very closely the concepts of [[TransationalMemory]]. For lack of better name, let's call them [[TransactionalDataStructure]]s. | ||
| + | |||
| + | Read on to [[TransactionalDataStructure]] article to learn what '''best to take''' from [[TransactionalDataStructure]], how to fight [[deadlock]]s and even [[deadlock]] when designing an [[API]] when certainly part of the code isn't under your control and can do anything (wild). | ||
| + | |||
| + | |||
| + | == Meta Conclusion == | ||
| + | |||
| + | A more meta-level thought: Joe's [http://joeduffyblog.com/2010/01/03/a-brief-retrospective-on-transactional-memory/ text] shows why it is important to properly document failures. Why it is important to describe roads that lead nowhere. As [[wikipedia:Jára_Cimrman|Jára Cimrman]] says: Should not we value the person who tried to blow a cigarette smoke into watter to find out that this process does not produce gold? Thanks Joe for showing us that (weak) [[TransactionalMemory]] does not help to build reliable programming environment. | ||
Current revision
TransactionalMemory is an attempt to bring the power of databases to general purpose programming languages. Read below to learn how such an effort failed, but also how to take the best of it!
Overview & History (of the failure)
wikipedia:Transactional Memory should be the ultimate source of information, however it seems that much better understanding of TransactionalMemory can be obtained by reading follwing practitioner's report. Joe Duffy's text is worth reading - it shows why weak TransactionalMemory cannot work. In the process of showing that it describes the gory details that remain unnoticed in the general overview at wikipedia:Transactional Memory.
As far as I can tell Joe's write up is one of the best texts on internet I have read in months. It is deep, detailed, informative, entertaining and contains pieces of wisdom you don't want to miss. Like the "these kinds of moments make me a believer in formal computer science" acknowledgement.
TransactionalDataStructure
Looking back at Joe's fifteen years old post, I have to nod: The TransactionalMemory buzz is over. I haven't hard about TransactionalMemory, but that doesn't mean the whole idea was wrong! Recently (at GeeCON 2025) I heard a presentation about LockFreeAlgorithms. The name didn't ring any bell in my head, but after a while I realized it is actually talking about data structures that resemble very closely the concepts of TransationalMemory. For lack of better name, let's call them TransactionalDataStructures.
Read on to TransactionalDataStructure article to learn what best to take from TransactionalDataStructure, how to fight deadlocks and even deadlock when designing an API when certainly part of the code isn't under your control and can do anything (wild).
Meta Conclusion
A more meta-level thought: Joe's text shows why it is important to properly document failures. Why it is important to describe roads that lead nowhere. As Jára Cimrman says: Should not we value the person who tried to blow a cigarette smoke into watter to find out that this process does not produce gold? Thanks Joe for showing us that (weak) TransactionalMemory does not help to build reliable programming environment.
Follow
