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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.