Discussions of the Parallel Programming book
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Yubin Ruan <ablacktshirt@gmail.com>
Cc: perfbook@vger.kernel.org
Subject: Re: STM implementation
Date: Mon, 15 Jan 2018 07:50:17 -0800	[thread overview]
Message-ID: <20180115155017.GI9671@linux.vnet.ibm.com> (raw)
In-Reply-To: <20180115142809.GA28308@HP>

On Mon, Jan 15, 2018 at 10:28:33PM +0800, Yubin Ruan wrote:
> Hi Paul,
> 
> I writing to ask about implementation of STM (software transactional memory).
> 
> I just finish section 17 of the perfbook, but that doesn't say much about
> implementations of transactional memory, especially STM. Basically I
> understand the common implementation of HTM (hardware transactional memory)
> and have experience using it (thanks to the meltdown paper[1] and the original
> HTM paper[2] and some other materials[3]). But I cannot find useful materials
> on the topic of STM implementation. I read through the original STM paper[4],
> but found it a bit cryptographic (hard to understand). Based on the materials
> I read so far, STM can be implemented using lock-free algorithms or simply
> locking. Alternatively, it can also be implemented using techniques similar to
> those in the database world (write-ahead logging, i.e., journaling). But I
> guess a robust and efficient implementation will require more to handle issues
> such as I/O ? Can you provide some hints on this topic?
> 
> I am still investigating and will really appreciate any comments.

Hello, Yubin,

There has been a huge variety of STM implementations over the years.
Last I looked into it carefully (admittedly some years back), there was
a tradeoff between performance and scalability, but both performance
and scalability were quite poor compared to non-TM approaches.

A colleague of mine had good things to say about SwissTM, but that was
more than five years ago.  Michael Spear has done quite a bit of more
recent STM work, so looking at his publications would be helpful.

Please let me know how it goes!

							Thanx, Paul

>         Yubin
> 
> [1]: https://meltdownattack.com/meltdown.pdf
>     (The meltdown paper)
> 
> [2]: http://cs.brown.edu/~mph/HerlihyM93/herlihy93transactional.pdf
>     (Transactional Memory: Architectural Support for Lock-Free Data Structures)
> 
> [3]: https://www.scss.tcd.ie/~jones/CS4021/transactional%20memory.pdf
>     (A lecture note on Intel TSX, which also talk about implementation of HTM)
> 
> [4]: https://pdfs.semanticscholar.org/846e/87f6c8b9d8909d678b5c668cfe46cf40a348.pdf
>     (Software Transactional Memory)
> 


      reply	other threads:[~2018-01-15 15:50 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-15 14:28 STM implementation Yubin Ruan
2018-01-15 15:50 ` Paul E. McKenney [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180115155017.GI9671@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=ablacktshirt@gmail.com \
    --cc=perfbook@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox