The only way forward IMO, is either a pessimistic STM which restores reasoning and composition for transactions [1], or preferably, declaratively stating the commutative properties of concurrent variables so concurrency is fully deterministic and inherently eventually consistent [2]. One of their earliest papers on concurrent revisions ported a game and demonstrated promising near-linear speedups [3]. They've since extended it to include transparent parallel and incremental computation [4], all using the same API.
It's the most promising API for scaling mutable state I've seen to date. Sandro [1] http://mcg.cs.tau.ac.il/papers/transact2012-pessimistic.pdf [2] http://research.microsoft.com/en-us/projects/revisions/ [3] http://research.microsoft.com/apps/pubs/default.aspx?id=132619 [4] http://research.microsoft.com/apps/pubs/default.aspx?id=150180 On 18/09/2013 10:50 PM, David Jeske wrote:
Fishing around the STM+GC integration, I found these references which seem to be remotely related to Carmack's brainstorm.."Synchronization phases (to speed up transactional memory)" - this is the closest research I can find.http://www.tik.ee.ethz.ch/file/82b807b0317988c73dbe6025e3aeb4c3/TIK-Report-340.pdf"Concurrent GC leveraging Transactional Memory" - while this is general write-contention STM not Carmack's no-write-contention "phase flipping" concept. they shared some of the copying and barriers between the STM and GC subsystems. They achieve low average pause times and per-thread pausing rather than stop-the-world, However, they have no bound on worst-case pause times, which in their test was still >100ms.http://dl.acm.org/citation.cfm?id=1345238 PyPy STM + GC experiments: http://morepypy.blogspot.com/2013/06/stm-on-drawing-board.html http://morepypy.blogspot.com/2013/07/software-transactional-memory-lisp.html _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
