Talk:Software transactional memory

message: I've received some negative feedback about this article from friends. I'm currently researching the area and will improve it in the future. Deco 21:50, 3 February 2006 (UTC)
replies: text: Sorry for not answering, didn't see this. In short it was missing a lot of information, and the English was also a bit messy. I've rewritten it. I hope the original author is not offended - there's plenty of room for additional expansion still. Deco 23:47, 8 February 2006 (UTC)

text: It's a loss on small numbers of processors, but a gain on larger numbers. Sorry if the wording was unclear. You're right that the theoretical worst-case is considerably worse than the typical overhead observed in experiments. Deco 22:52, 19 June 2006 (UTC)

message: Quoted from the article:
 atomic {
     if (x != y)
         while (true) { }
 }
Transaction A	
 atomic {
     x++;
     y++;
 }
Transaction B
Provided x=y initially, neither transaction above alters this invariant, but it's possible transaction A will read x after transaction B updates it but read y before transaction B updates it, causing it to enter an infinite loop.
Hmmm - isn't it the point of transactions that the intermediate state "x == y+1" is NOT visible anywhere outside of transaction B? "Commit" is an atomic operation, isn't it??? --84.137.86.147 22:25, 4 March 2006 (UTC)
replies: text: Right. The transaction A has read inconsistent state committed by transaction B, which prevents transaction A from committing successfully, but that doesn't mean it'll terminate. Deco 22:52, 19 June 2006 (UTC)

text: That's true. Whether or not this leads to nontermination depends on the specific implementation of STM. Deco 00:47, 9 January 2007 (UTC)

text: To what section are you referring? There is no consistence problem with any implementation of STM, including the one I originally described - if the transaction has read inconsistent state it will abort if it completes. The issue is nontermination, which necessitates a timeout. Deco 18:52, 9 January 2007 (UTC)
replies: text: I'm talking about the section showing partial transactions (partial update states) visible to other processes. That section talks about seeing "impossible" states because of that. Since we are talking about "transactional" memory, a correct implementation would be ACI (ACID without the D) and so other concurrent threads should not see partially updated states. A "real" transactional memory implementation should detect the inconsistence when reading "stale" data, at that time, long time before the commit. Jcea 15:31, 10 January 2007 (UTC)

text: I have restored the section. The paper on which it is based specifically describes this scenario in very similar terms, and claims to implement a software transactional memory. If you contest this claim, then you need to take that up with the original authors. I've emphasized many times that the reading of stale data is possible only because reading is optimistic in this implementation, and no transaction having read such data ever commits. Not all STM implementations guarantee that stale data is never read, only that transactions reading it cannot succeed, which preserves the ACI properties. Deco 19:40, 26 January 2007 (UTC)
replies: text: I added a small comment about "conflict" exceptions raising when reading/writing stale data. With this small change, I'm satisfied :-) Jcea 18:16, 2 April 2007 (UTC)
replies: text: I'm afraid I had to delete this comment because it's not accurate - it seems that you're still missing the point. To check every access up front to see whether it's violating serializability would be prohibitively costly. The whole point of an optimistic approach is to delay this cost until commit time. Again, it does not matter if a transaction reads stale data, as long as that transaction is from then on unable to commit. This is not a small issue, it is fundamental to how optimistic reading works. Dcoetzee 18:00, 6 April 2007 (UTC)
thread_title:  Implementation issues 

message: What exactly qualifies an STM implementation as being "large-scale
product-quality"? I know a number of people who are using Haskell/STM in
a non-research (at least, not research on STM) context. In other news,
Audrey-tan has
incorporated STM
into Perl 6. (Is this product-quality yet? Or large-scale enough?)
Liyang 21:40, 19 June 2006 (UTC)
replies: text: Honestly, I wasn't familiar with those implementations. The current claim might be misleading; feel free to edit it, but I personally wouldn't tell anyone that STM is ready for major software projects. Deco 22:52, 19 June 2006 (UTC)
thread_title:  Implementations 

message: I've just gotten access to a more comprehensive and up-to-date reference regarding software transactional memory and I intend to expand the article based on it. Stay tuned. Dcoetzee 17:54, 6 April 2007 (UTC)
thread_title:  Expansion coming 

message: I added a section on transactional locking, which overcomes the problem mentioned in "implementation issues". I think this work by Dice, Shalev, Shavit defines the state of the art in STM.
Bartosz 20:20, 18 August 2007 (UTC)
thread_title:  Transactional Locking 

message: The article says "One way to deal with these issues is to detect transactions that ... fail to terminate and abort them cleanly"
I don't think that's possible with a Turing-complete computer language.  http://en.wikipedia.org/wiki/Halting_problem.
The text should have more explanation, or be removed as a possible solution.  Like, should atomic operations have a time limit, like a timeout of a select() call?  —Preceding unsigned comment added by 62.163.31.210 (talk) 11:48, 1 October 2007 (UTC)
thread_title:  Detecting failure to terminate 

message: In section "Transactional locking" the author not only mentions (pending?) patents on STM but quotes from a specific patent, viz:
(Zhang et al. 2006[6]) is a US patent entitled "Software transaction commit order and conflict management" (which references CO US patent 5701480). Its abstract part is the following: <snip>
I would prefer that Wikipedia articles not quote patents directly unless it is the primary source on the matter. Patent law is strange: just by having seen some of the patent text on Wikipedia, if I write/use a STM, the patent holder may claim that I have 'knowingly infringed'. Don't know if there is a wiki policy on this but perhaps there should be...
The article also make many quite unsupported/unreferenced assertions, eg "Tens of STM articles and patents utilizing "commit order" have already been published."
Please excuse my lack of wiki markup language skills.  — Preceding unsigned comment added by 121.214.116.38 (talk) 18:06, 31 August 2011 (UTC)
thread_title:  Quoting specific Patents undesirable  

message: The neutrality of part of this page is disputed, as part of a wider discussion. See Talk:Commitment ordering and Wikipedia talk:WikiProject Computer science#User:Comps / Commitment ordering. —Ruud 14:34, 23 December 2011 (UTC)
replies: text: No progress since 2011? 71.19.161.130 (talk) 20:16, 5 February 2015 (UTC)
thread_title:  Commitment ordering 

message: Hello fellow Wikipedians,
I have just added archive links to  on Software transactional memory. Please take a moment to review my edit. If necessary, add  after the link to keep me from modifying it. Alternatively, you can add  to keep me off the page altogether. I made the following changes:
*Added archive https://web.archive.org/20080601163025/http://www.hackshack.de:80/tarifa/ to http://www.hackshack.de/tarifa/
When you have finished reviewing my changes, please set the checked parameter below to true to let others know.
Cheers.—cyberbot IITalk to my owner:Online 19:23, 12 February 2016 (UTC)
thread_title:  External links modified 

message: It's dead and not archived as far as I can tell, so I have marked it as such. I found a copy at https://www.cs.tau.ac.il/~shanir/nir-pubs-web/Papers/Transactional_Locking.pdf, BUT I don't know if that's a legal (re copyright and friends) publication of it or if that matters. 86.145.226.161 (talk) 12:13, 25 September 2019 (UTC)
thread_title:  Transactional Locking II Paper Link