veyepar: High-Performance and Scalable Updates: The Issaquah Challenge

Author(s):	Paul McKenney
Location	Case Room 3
Date	jan Fri 16	Days Raw Files
Start	11:35	First Raw Start	11:27
Duration	0:45:00	Offset	0:07:18
End	12:20	Last Raw End	12:26
Chapters	00:00
Total cuts_time	48 min.

http://lca2015.linux.org.au/schedule/30142/view_talk
raw-playlist raw-mp4-playlist encoded-files-playlist host public tweet mp4 svg png

assets release.pdf HighPerformance_and_Scalable_Updates_The_Issaquah_Challenge.json
logs
Admin: episode episode list cut list raw files day marks day marks day image_files

State:

Locked:

clear this to unlock

Locked by:

user/process that locked.

Start:

initially scheduled time from master, adjusted to match reality

Duration:

length in hh:mm:ss

Name:

Video Title (shows in video search results)

Emails:

email(s) of the presenter(s)

Released:

has someone authorised pubication

Normalise:

Channelcopy:

m=mono, 01=copy left to right, 10=right to left, 00=ignore.

Thumbnail:

filename.png

Description:

markdown

Highly performant and scalable techniques such as RCU have been quite successful in read-mostly situations.  However, there do come times when updates are necessary.   It would be convenient if there was some general update-side counterpart to RCU, but sadly there is not yet any such thing.  Nevertheless, there are a number of specialized update-side techniques whose performance and scalability rival that of RCU.  This talk will discuss several of them and provide an outlook into the future of low-overhead scalable updates.

One technique is the solution to the Issaquah Challenge, which was put forward at the C++ standards committee meeting in early 2014 at Issaquah, WA, USA.  This challenge requires a performant and scalable technique to atomically move elements back and forth between a pair of search trees, but without using transactional memory.  This talk will give an overview of a solution to a more general problem, that of atomically moving groups of elements among a group of several different types of linked data structures, while still permitting lockless searches before, during, and after this atomic move.

Comment:

production notes