I've read two quite different accounts of how STM is implemented. Perhaps both are valid, or one is mistaken, and I hoping someone can shed light.
Take 1 (wikipedia): all threads are allowed to modify shared memory, but every read and write within the transaction is logged. At the end of the transaction the system checks that other threads have not concurrently made changes to memory. If no changes were made, transaction is committed. Otherwise, transaction is restarted.
Take 2 (can't find source): When a program enters transaction, it gets a copy of all variables contained within and can go to town on them. At the end of the transaction the system tries to update the master with the copy. If the master hasn't changed since the copy was first made, then the transaction is committed. Otherwise, transaction is restarted.
Also, what happens when two threads enter the same transaction at the same time? Doesn't this cause a race condition of sorts? Since both are attempting to modify the same shared memory, both will need to be restarted and the issue continue ad infinitum unless the system steps in and tell one thread to cool it (sort of like a lock =) I'm sure I'm missing a concept here.
I'm not an expert but have read a few papers. As is common with proposals for new technologies, it looks like one group proposed STM, but subsequent work by other groups looked at variations. There are more than the two you mention. For example, this paper gives a mechanism that has blocking locks on transactions rather than the aggressive non-blocking approach in both of yours: http://pages.cs.wisc.edu/~david/courses/cs758/Fall2007/papers/saha-mcrt-ppopp-2007.pdf The only common thread among implementation techniques seems to be the database-like transaction semantics. So the central question of the research is about whether these semantics lead to better programs and/or more efficiency in general. How they're implemented is up for grabs.
Also, what happens when two threads enter the same transaction at the same time? Doesn't this cause a race condition of sorts? Since both are attempting to modify the same shared memory, both will need to be restarted...
Not really. The system always makes progress because when 2 or more commits are in conflict, the log allows all to be rolled back to the point where the conflicting transactions started. Then the threads can be allowed to proceed and commit sequentially. You're right this causes duplicate work, especially when a single object is in high demand. However avoiding this would be worthwhile only when its more costly than a context swap. The STM folks are betting that memory conflicts are comparatively rare. The Wikipedia scheme is particularly aggressive in this assumption.