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)
>
prev parent 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