Monday 27th June 2016: 10.58am.My CppCon talk "Memory mapped distributed mutual exclusion using Proposed Boost.AFIO (asynchronous filesystem and file i/o)" has been accepted for presentation at CppCon 2016 in Seattle this September. My thanks to the Programme Committee for taking a bit of a risk on this topic, because as you'll see from the proposed abstract it is not certain if the topic is even feasible (if it isn't, I'll present the results of my failure :) )
"At CppCon 2015 we studied the concurrency fundamentals of the filing system (https://www.youtube.com/watch?v=uhRWMGBjlO8). At ACCU 2016, using the post-peer-review ongoing v2 rewrite of proposed Boost.AFIO and from solely the concurrency fundamental technique atomic append and extent deallocation, we built a novel distributed mutual exclusion implementation boost::afio::algorithm::atomic_append performance competitive with boost::afio::algorithm::byte_ranges and boost::afio::algorithm::lock_files (https://www.youtube.com/watch?v=elegewDwm64).
At the ACCU 2016 workshop, we saw how each of these three distributed mutual exclusion algorithms provided in boost::afio::algorithm had strengths and weaknesses relative to one another in scalability, and in contended and uncontended usage. At this workshop we shall continue the theme by building a fourth distributed mutual exclusion algorithm for the AFIO algorithms library, with this one making use of shared memory maps for superior performance when only a single machine is doing the locking. Is it possible to portably detect the arrival of a networked drive user (SMB, NFS) and safely disable using shared memory maps such that we can automatically downgrade our implementation to a networked drive compatible technique?
At the time of writing this Call for Papers, it is believed this fourth mutual exclusion strategy should be feasible on Microsoft Windows and Linux, but it is an open question if the implementation can be made portable. It is completely unknown what kind of scalability to load or performance this algorithm might have. Let’s find out!"