<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Arial",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> stevenwu@apple.com <stevenwu@apple.com>
<br>
<b>Sent:</b> Monday, March 26, 2018 6:33 PM<br>
<b>To:</b> Romanova, Katya <katya.romanova@sony.com><br>
<b>Cc:</b> tejohnson@google.com; joker.eph@gmail.com; rafael.espindola@gmail.com; peter@pcc.me.uk; hans@chromium.org; rnk@google.com; bd1976llvm@gmail.com; llvm-dev@lists.llvm.org<br>
<b>Subject:</b> Re: [pre-RFC] Data races in concurrent ThinLTO processes<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Mar 26, 2018, at 6:03 PM, <a href="mailto:katya.romanova@sony.com">
katya.romanova@sony.com</a> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif;color:#1F497D">Hi Steven,</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif;color:#1F497D">Look at my replies inline (below your comments).</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif;color:#1F497D">Katya.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<div>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span class="apple-converted-space"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span></span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><a href="mailto:stevenwu@apple.com"><span style="color:purple">stevenwu@apple.com</span></a><span class="apple-converted-space"> </span><<a href="mailto:stevenwu@apple.com"><span style="color:purple">stevenwu@apple.com</span></a>><span class="apple-converted-space"> </span><br>
<b>Sent:</b><span class="apple-converted-space"> </span>Thursday, March 22, 2018 4:46 PM<br>
<b>To:</b><span class="apple-converted-space"> </span>Romanova, Katya <<a href="mailto:katya.romanova@sony.com"><span style="color:purple">katya.romanova@sony.com</span></a>><br>
<b>Cc:</b><span class="apple-converted-space"> </span>Teresa Johnson <<a href="mailto:tejohnson@google.com"><span style="color:purple">tejohnson@google.com</span></a>>; Mehdi AMINI <<a href="mailto:joker.eph@gmail.com"><span style="color:purple">joker.eph@gmail.com</span></a>>;
Rafael Avila de Espindola <<a href="mailto:rafael.espindola@gmail.com"><span style="color:purple">rafael.espindola@gmail.com</span></a>>; Peter Collingbourne <<a href="mailto:peter@pcc.me.uk"><span style="color:purple">peter@pcc.me.uk</span></a>>; Hans Wennborg
<<a href="mailto:hans@chromium.org"><span style="color:purple">hans@chromium.org</span></a>>; Reid Kleckner <<a href="mailto:rnk@google.com"><span style="color:purple">rnk@google.com</span></a>>;<span class="apple-converted-space"> </span><a href="mailto:bd1976llvm@gmail.com"><span style="color:purple">bd1976llvm@gmail.com</span></a>;<span class="apple-converted-space"> </span><a href="mailto:llvm-dev@lists.llvm.org"><span style="color:purple">llvm-dev@lists.llvm.org</span></a><br>
<b>Subject:</b><span class="apple-converted-space"> </span>Re: [pre-RFC] Data races in concurrent ThinLTO processes</span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Hi Katya<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Thanks for investigating this. Here is my thought inline.<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><br>
<br>
<br>
<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">On Mar 22, 2018, at 1:32 AM,<span class="apple-converted-space"> </span><a href="mailto:katya.romanova@sony.com"><span style="color:purple">katya.romanova@sony.com</span></a><span class="apple-converted-space"> </span>wrote:<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">Hello,</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">I am sending the following proposal to discuss issues and solutions regarding data races in concurrent ThinLTO processes.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">This caught my attention when we encountered a race condition in ThinLTO with caching.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">While looking into how ThinLTO deals with the problem of cache files reads/writes/deletes I spotted a lot of problems: some of them are related to data races, others - to file/resource
sharing between different processes. I wanted to point out these problems and start the discussion about potential solutions. I would like to get your feedback.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New"">Problem #1: In certain common situations, ‘rename’ can fail, causing a data race later on.</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">Look at the following code in the function ‘write’ in ThinLTOCodeGenerator.cpp</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0">std::error_code EC =</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0"> sys::fs::createTemporaryFile("Thin", "tmp.o", TempFD, TempFilename);</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0">if (EC) {</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0"> errs() << "Error: " << EC.message() << "\n";</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0"> report_fatal_error("ThinLTO: Can't get a temporary file");</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0">}</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0">{</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0"> raw_fd_ostream OS(TempFD, /* ShouldClose */ true);</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0"> OS << OutputBuffer.getBuffer();</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0">}</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0">// Rename to final destination (hopefully race condition won't matter here)</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0">EC = sys::fs::rename(TempFilename, EntryPath); </span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">Compared to a race-prone direct write of a buffer to a file, this code avoids a data race by first writing a buffer to a temp file and then renaming that temp file to become the final
file in the cache. After r315079, when ‘rename’ became more POSIX-compliant, this scheme guarantees atomicity of writing a file to the cache,</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">(except on Wine, where (in some cases) non-atomic ::MoveFileExW is used).</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New""> </span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">However, ‘rename’ might fail and return an error code in several different situations. If this happens, we will fall back to a direct write to the file, which is neither atomic, nor
avoids race conditions (causing problem #3).</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">An<span class="apple-converted-space"> </span>example where 'rename' can fail on both Windows and Unix-like systems, causing us to fall back to using non-atomic write, is problem
#2.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New"">Solution:</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">All solutions for problem #3 (see below) will take care of problem #1.</span><o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal">I don't think there is a race here but it can probably be optimized. I don't see LTOCodeGenerator fall back to non-atomic write in the code. If the rename failed, it will just fatal_error and exit. Maybe a better solution is just leave
the temp file and use it as output. The file will be recompiled if needed again (turns into a cache miss).<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><br>
<span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D">I think there is a non-atomic write (and race) here. See below. If rename failed, we remove the temp file and write to the cache file directly (OS << OutputBuffer.getBuffer()).</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D"> // Rename to final destination (hopefully race condition won't matter here)</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D"> EC = sys::fs::rename(TempFilename, EntryPath);</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D"> if (EC) {</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D"> sys::fs::remove(TempFilename);</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D"> raw_fd_ostream OS(EntryPath, EC, sys::fs::F_None);</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D"> if (EC)</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D"> report_fatal_error(Twine("Failed to open ") + EntryPath +</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D"> " to save cached entry\n");</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D"> OS << OutputBuffer.getBuffer();</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D"> }</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D"> }</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D">What we can do the following way:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D">Option 1: If the rename fails, we could simply use OutputBuffer (which has the same content as our temp file), bypassing the cache altogether.</span><o:p></o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Option 1 is much better for the current model. To be safe, we should avoid non-atomic write (which is directly writing the cache file) to the cache. When we perform such write, the cache is in an invalid state and we have nothing to prevent
reading from it.<o:p></o:p></p>
</div>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif;color:#1F497D">I agree.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D">Option 2: We could try reading from the existing cache first, and then, if this read fails, we could use OutputBuffer (in this case, we will be closer to the existing
code). I don’t understand why do we have to read from the existing cache first (even if we just created this cache). I suspect this was done for a reason. There is a comment below with the explanation, but it doesn’t make it more clear to me. If this reason/explanation
makes sense, then we should do Option 2. This is exactly what I previously proposed in Solution #0 for Problem #3. </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;color:#1F497D"> // Commit to the cache (if enabled)</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;color:#1F497D"> CacheEntry.write(*OutputBuffer);</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;color:#1F497D"> if (SavedObjectsDirectoryPath.empty()) {</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;color:#1F497D"> // We need to generated a memory buffer for the linker.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;color:#1F497D"> if (!CacheEntryPath.empty()) {</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;color:#1F497D"> // Cache is enabled, reload from the cache</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;color:#1F497D"> // We do this to lower memory pressuree: the buffer is on the heap</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;color:#1F497D"> // and releasing it frees memory that can be used for the next input</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;color:#1F497D"> // file. The final binary link will read from the VFS cache</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;color:#1F497D"> // (hopefully!) or from disk if the memory pressure wasn't too high. <- I don’t understand why we are reading from the cache file (via tryLoadingBuffer), though we
already have the same content in OutputBuffer?</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;color:#1F497D"> auto ReloadedBufferOrErr = CacheEntry.tryLoadingBuffer(); <-The explanation says this is done to reduce the memory pressure. But it’s not clear to me why
this helps to reduce memory pressure, since we still have to keep</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;color:#1F497D"> if (auto EC = ReloadedBufferOrErr.getError()) { <- the content of the cache file in a buffer, pointed to by ReloadedBufferOrErr). </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;color:#1F497D"> // On error, keeping the preexisting buffer and printing a</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;color:#1F497D"> // diagnostic is more friendly than just crashing.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;color:#1F497D"> errs() << "error: can't reload cached file '" << CacheEntryPath</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;color:#1F497D"> << "': " << EC.message() << "\n";</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;color:#1F497D"> } else {</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;color:#1F497D"> OutputBuffer = std::move(*ReloadedBufferOrErr);</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;color:#1F497D"> }</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;color:#1F497D"> }</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New"">Problem #2 (Use of POSIX-compliant ‘rename’ function is not always suitable for ThinLTO)</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">We just encountered this issue in Sony. For ThinLTO, we use the function ‘rename’, which after r315079 doesn’t support renaming across the different logical volumes on Windows.<span class="apple-converted-space"> </span></span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">Let’s say a user has a %TEMP% directory on volume C:\, but he/she passed the caching directory name located on volume D:\, then ‘rename’ fails. Since we don’t support renaming across
different volumes after r315079, we then fall back to writing to the cache file directly (which is not atomic) and hit a data race.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">We anticipate that this will be a common situation for our users, many of whom are Windows “power users” and have multiple disks for different purposes.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">I think this problem doesn’t only affect Windows. The same issue might happen on Linux/MacOS, if the user's $TEMP/$TMP directory is located in a different file system than the user-specified
caching directory.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New"">Solution #1 (not so good):</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">The patch below solves this problem on Windows, however, we will lose the advantage that ‘rename’ gained in r315079 (i.e., its atomicity), which is not good.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">This patch assumes that the function 'rename' in Windows/Path.inc is expected to work when the source and destination are located of different logical volumes or different file systems.
Note that function ‘rename’ is not ThinLTO-specific and might have some other consumers who want this behavior (which was the behavior before r315079). However, it seems that this assumption has changed later to make ‘rename’ more POSIX-compliant. In this
case, we should add a comment to the function 'rename' so that its users knew that renaming across different volumes is not supported by design. Or we could have two different functions, one POSIX-compliant, not allowing renames across different volumes, another
non-POSIX-compliant.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">Before r315079, the function 'rename', (in the case when the destination file isn't opened), boiled down to calling the function 'MoveFileExW' with the MOVEFILE_COPY_ALLOWED flag
set, allowing renaming files across the volumes.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">The current implementation of the function ‘rename’ (in 'rename_internal'), essentially calls 'SetFileInformationByHandle'. This function is fast and atomic, so in a sense, it's an
improvement over the previously used 'MoveFileExW'. However, 'SetFileInformationByHandle' doesn't work when the source and destination are located on the different volumes.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">My fix just falls back to calling 'MoveFileExW' when 'SetFileInformationByHandle' returns an error 'ERROR_NOT_SAME_DEVICE'.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#002060"> </span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0">+ // Wine doesn't support SetFileInformationByHandle in rename_internal.</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0">+ // Rename_internal doesn't work accross different disks. In both of these</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0">+ // cases fall back to using MoveFileEx.</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0"> if (EC ==</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0">- std::error_code(ERROR_CALL_NOT_IMPLEMENTED, std::system_category())) {</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0">- // Wine doesn't support SetFileInformationByHandle in rename_internal.</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0">- // Fall back to MoveFileEx.</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0">+ std::error_code(ERROR_CALL_NOT_IMPLEMENTED, std::system_category()) ||</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0">+ EC == std::error_code(ERROR_NOT_SAME_DEVICE, std::system_category())) {</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0"> SmallVector<wchar_t, MAX_PATH> WideFrom;</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0"> if (std::error_code EC2 = realPathFromHandle(FromHandle, WideFrom))</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0"> return EC2;</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0"> if (::MoveFileExW(WideFrom.begin(), WideTo.begin(),</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0">- MOVEFILE_REPLACE_EXISTING))</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0">+ MOVEFILE_COPY_ALLOWED | MOVEFILE_REPLACE_EXISTING))</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0"> return std::error_code();</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0"> return mapWindowsError(GetLastError());</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0"> }</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">Note, that when the source and destination are located on the different logical volumes, we will effectively perform a copy, followed by a delete, which are not atomic operations.
Since copying to a different volume might be quite time consuming, we also increase the probability that some other process starts to rename to the same destination file.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">So, this fix for ‘rename’ is not good for ThinLTO (we should do something else in this case). ‘rename’ is a generic function and has many different users, but unless renaming across
the volumes is needed by someone else, other than ThinLTO, this patch shouldn’t be accepted.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New"">Solution #2 (better)</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">Here I only try to fix a ThinLTO issue, not a generic ‘rename’ issue as in solution #1:</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">For ThinLTO+caching we don’t have to create temp files in %TEMP% or %TMP% directories (or $TMP/$TEMP). We can create them in the same location where the cached files are stored or
in a ‘temp’ subfolder within this folder. With this approach:</span><o:p></o:p></p>
</div>
</div>
<div style="margin-left:.5in">
<div>
<p class="MsoNormal" style="text-indent:-.25in"><span style="font-size:18.0pt;font-family:"Courier New"">-</span><span style="font-size:7.0pt"> <span class="apple-converted-space"> </span></span><span style="font-size:18.0pt;font-family:"Courier New"">If the
patch described in Solution #1 gets accepted (for the sake of other consumers), then from ThinLTO’s perspective ‘rename’ will stay atomic.</span><o:p></o:p></p>
</div>
</div>
<div style="margin-left:.5in">
<div>
<p class="MsoNormal" style="text-indent:-.25in"><span style="font-size:18.0pt;font-family:"Courier New"">-</span><span style="font-size:7.0pt"> <span class="apple-converted-space"> </span></span><span style="font-size:18.0pt;font-family:"Courier New"">If the
patch doesn’t get accepted, then rename won’t fail, since we only rename the files within the same directory.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#002060"> </span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#002060">Solution #3</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">All the solutions for problem #3 (see below) will take care of problem #2.</span><o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal">I am surprised that we are not doing #2 already. Rename across the volumes is not atomic thus it can cause issues.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><br>
<span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D">Yes, we are calling createTemporaryFile, which creates a file in the location pointed by $TEMP, $TMP, etc.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D"> sys::fs::createTemporaryFile("Thin", "tmp.o", TempFD, TempFilename);</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D">So, it looks like this problem is applicable to Unix-like systems too (assuming that your $TEMP and cache directory are in the different file systems).</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I don't think there is a file system that supports atomic rename between volumes. This is something we can fix easily.<o:p></o:p></p>
</div>
<p class="MsoNormal"><span style="color:#1F497D">Yes, this is an easy fix.</span><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#002060"> </span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#002060"> </span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New"">Problem #3 (data race)</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">Look at the following code in ThinLTOCodeGenerator.cpp. This code gets executed if the ‘rename’ function failed (e.g., because of the problem #1 or problem #2 described above).</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0">EC = sys::fs::rename(TempFilename, EntryPath);</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0">if (EC) {</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0"> sys::fs::remove(TempFilename);</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0"> raw_fd_ostream OS(EntryPath, EC, sys::fs::F_None);</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0"> if (EC)</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0"> report_fatal_error(Twine("Failed to open ") + EntryPath +</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0"> " to save cached entry\n");</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0"> OS << OutputBuffer.getBuffer(); <span class="apple-converted-space"> </span></span></b><b><span style="font-size:18.0pt;font-family:"Courier New";color:red">//
Two ThinLTO processes can write to the same file here</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:red"> // causing data race.</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">Here, we have a data race problem. We actually stumbled across it while testing one of the games with ThinLTO+caching.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">We need to find a generic solution to solve data race problem, while ensuring ‘atomicity’ of writing to cache files. I’m not a ThinLTO expert and I might not be aware of some ThinLTO
constraints. Let me know which problems you see with the two solutions below. Hopefully, it will trigger a further discussion.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New"">Solution #0 (it won’t require much modifications):</span></b><o:p></o:p></p>
</div>
</div>
<div style="margin-left:.85in">
<div>
<p class="MsoNormal" style="text-indent:-.6in"><span style="font-size:18.0pt;font-family:"Courier New"">(a)</span><span style="font-size:7.0pt"> <span class="apple-converted-space"> </span></span><span style="font-size:18.0pt;font-family:"Courier New"">If
‘rename’ fails, do not write into the cache directly (we don’t want to have non-atomic writes!).</span><o:p></o:p></p>
</div>
</div>
<div style="margin-left:.85in">
<div>
<p class="MsoNormal" style="text-indent:-.6in"><span style="font-size:18.0pt;font-family:"Courier New"">(b)</span><span style="font-size:7.0pt"> <span class="apple-converted-space"> </span></span><span style="font-size:18.0pt;font-family:"Courier New"">If
‘rename’ fails, try to read from the cache. </span><o:p></o:p></p>
</div>
</div>
<div style="margin-left:.85in">
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New";color:#0070C0">auto ReloadedBufferOrErr = CacheEntry.tryLoadingBuffer();</span></b><o:p></o:p></p>
</div>
</div>
<div style="margin-left:.85in">
<div>
<p class="MsoNormal" style="text-indent:-.6in"><b><span lang="EN-GB" style="font-size:18.0pt;font-family:"Courier New"">(c)</span></b><b><span lang="EN-GB" style="font-size:7.0pt"> <span class="apple-converted-space"> </span></span></b><span style="font-size:18.0pt;font-family:"Courier New"">If
reading from the cache fails simply use the file that you just compiled directly (bypassing the cache entirely).</span><o:p></o:p></p>
</div>
</div>
<div style="margin-left:.85in">
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div style="margin-left:.85in">
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">This solution might cause cache misses (causing recompilations), but at least it should prevent data races when two ThinLTO processes write to the same file (which can produce invalid
cache!). Correctness is more important than optimization. It’s worth noticing another shortage of this solution: unlike generic solution #1, #2 and #3 described below this particular solution won’t solve the problem #4.</span><o:p></o:p></p>
</div>
</div>
<div style="margin-left:.85in">
<div>
<p class="MsoNormal"><b><span lang="EN-GB" style="font-size:18.0pt;font-family:"Courier New""> </span></b><o:p></o:p></p>
</div>
</div>
<div style="margin-left:.85in">
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">BTW, we should do something with WINE support in ‘rename’ (which is non-atomic). I didn’t want to list it as a separate problem here, but it is a problem. I could file a separate
bug, if necessary.</span><o:p></o:p></p>
</div>
</div>
<div style="margin-left:.85in">
<div>
<p class="MsoNormal"><b><span lang="EN-GB" style="font-size:18.0pt;font-family:"Courier New""> </span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New""> </span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New"">Solution #1 (naïve generic solution):</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">(a) If the process wants to write to the cache file, it opens it with 'exclusive read/write' access.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">(b) If a process wants to write to the cache file that is ‘exclusively’ opened by some other process, we could assume that the cache file will be successfully created by the first
process and simply return from ‘write’ function. Different processes writing to the cache file of the same name, are writing the same content, right?</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">(c) If the process needs to read from the cache file, it might wait a bit while the file is open for 'exclusive write'. If within a certain period the cache file doesn’t get released
by a writer or gets removed by a pruner – oh, well, we have a hit miss. After all, using cache is just an acceleration. Correctness is more important.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">(d) If we are concerned about data integrity of a cache file (e.g., a writer started to write to a file and something bad happened in the middle), we could do additional checks (I
suspect that this might be already implemented in ThinLTO). A writer could add a unique hash at the end of the cache file or a CRC32 for each section of the file, which could be an indication that the write to this file was successful. A reader checks that
this unique hash or a CRC32 checksum matches its expectations.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">I'm sure that there are good reasons why this "naive" solution wasn't implemented in the first place. If this solution is picked by LLVM community, I could write a working prototype
for it that we could apply to ThinLTO.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New""> </span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New""> </span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New"">Solution #2 (better generic solution):</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">It looks like cache file sharing between several ThinLTO processes is a classic readers-writers problem.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""><a href="https://en.wikipedia.org/wiki/Readers%E2%80%93writers_problem"><span style="color:#954F72">https://en.wikipedia.org/wiki/Readers%E2%80%93writers_problem</span></a></span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">We could use read-write locks for global inter-process file sharing.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""><a href="https://en.wikipedia.org/wiki/Readers%E2%80%93writer_lock"><span style="color:#954F72">https://en.wikipedia.org/wiki/Readers%E2%80%93writer_lock</span></a></span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">ThinLTO's writer (creator/deleter) must acquire a write lock before writing to a file and release a write lock when it's done writing.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">ThinLTO’s user (reader) must acquire a read lock before reading a file and release a read lock when it's done reading. On a Unix-like system, read-write locks are part of POSIX-threads
(pthreads). There is an implementation of Slim read-write locks on Windows, but unfortunately for in-process only (i.e., the locks can’t be shared among different processes), so it won’t work for us.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""><a href="https://msdn.microsoft.com/en-us/library/windows/desktop/aa904937(v=vs.85).aspx"><span style="color:#954F72">https://msdn.microsoft.com/en-us/library/windows/desktop/aa904937(v=vs.85).aspx</span></a></span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">However, on Windows, we could implement read-write locks ourselves, using a combination of a named mutex and a named semaphore (any unique global name could be used for creating a
named mutex/semaphore, the simplest one will be the cache file name itself).</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">Here is an example of an implementation:</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""><a href="http://www.zachburlingame.com/2011/06/simple-reader-writer-lock-in-c-on-win32/"><span style="color:#954F72">http://www.zachburlingame.com/2011/06/simple-reader-writer-lock-in-c-on-win32/</span></a></span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">If this solution is picked, I could write a working prototype for it that we could apply to ThinLTO.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New"">Solution #3 (hybrid generic solution)</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">Basically, use solution #2 as a base and integrate some optimizations and completeness checking features from solution #1 (1.b and 1.d respectively).</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New""> </span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New"">Problem #4 (cache misses could have been avoided via synchronization).</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">With our current approach we might often race for the cache file resources and as a result have cache misses.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">Of course, it's not as dangerous as the data race problem #3, but it definitely lowers the efficiency of caching.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">(a) The reader checks that a file exists, but then the pruner deletes it before the reader had a chance to read it. Cache miss.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">(b) The reader starts reading a file (block by block) and at this time the pruner removes the file. The read might fail. This is OS-specific, but likely a cache miss.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">(c) If the writer will rename a temp file into a file that is currently being read by a reader, I don't expect anything good out of it (the behavior is OS-specific). In the best case
scenario, the read will fail, in the worst one the reader will read the wrong content. So, it's a cache miss or a correctness issue.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">(d) This is not a very likely event, but what if two processes are trying to rename to the same file at the same time?</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New"">Solution:</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">Solutions #1, #2 and #3 for problem #3 will take care of problem #4.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New"">(Potential) problem #5:</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">The<span class="apple-converted-space"> </span>implementation of the function ‘rename’ on Windows used by ThinLTO heavily depends on the function CreateFileW or, to be more exact,
on its flag FILE_SHARE_DELETE being supported and working correctly on *all* the file systems that can be mounted on Windows. Is the FILE_SHARE_DELETE flag supported on all non-native Windows file systems that we care about? Is it supported on WINE? On FAT32?</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">If the flag FILE_SHARE_DELETE is not supported, the ‘rename’ fails, and we have problem #3.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New""> </span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:18.0pt;font-family:"Courier New"">Solution:</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">All the solutions for problem #3 will take care of problem #5.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">Please let me know what do you think about the problems/solutions discussed here. Hopefully this pre-RFC shapes into a RFC soon.</span><o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
<div>
<div>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">I am not really concerned with all the problems, except Problem #2. From my understanding, LTO cache is for incremental build only.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D">Yes.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">For every file in the cache, there should be one single writer, otherwise, it is a hash collision and will result in miscompile (or link error most likely). The cached file will only be used when you rebuild the binary. Lots of data races
are in situations that are not supported.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D">Are you aware of any other data races when we share LTO cache between two links, except the one that we identified above? Please let me know. I’d rather know all
the potential problems/limitation in advance.</span><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The most common issue you are going to hit if you try to share LTO cache is that the file can be removed/updated when the other process is half way reading the file. I can consistently reproduce the issue if you try to build all LLVM/Clang
tools with a shared LTO cache.<o:p></o:p></p>
</div>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D">Are you talking about the potential situations that I described in the original proposal (namely, Problem #4)? I am a little confused. I thought that after reviewing
my proposal you said that these are not the real problems.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D">Problem 4(a): 1<sup>st</sup> process gets the file descriptor for the cache file; meanwhile the pruner from the 2<sup>nd</sup> process removes this cache file and
the 1<sup>st</sup> process fails to read it. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D">I don’t think that the problem that you are seeing. This is a cache miss. I don’t see how it could cause a miscompile.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D">Problem 4(b): 1<sup>st</sup> process starts reading the cache file block by block, while the pruner from the 2<sup>nd</sup> process deletes the cache file, before
the 1<sup>st</sup> process has a chance to finish reading it.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D">Are you encountering this situation? This is “most likely” not a problem on Windows, as long as the both processes open the cache file with FILE_SHARE_DELETE flag
(which we do) and as long as FILE_SHARE_DELETE flag is supported (which unfortunately is not the case for FAT32 or some other 3<sup>rd</sup> party file systems). Though you can never tell for sure about the Windows
</span><span style="font-size:14.0pt;font-family:Wingdings;color:#1F497D">J</span><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D">. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D">Obviously, this behavior is OS-specific. It will be safer if you ask MacOS Filesystem IO developers and find out for sure what will happen. There is a tiny chance
that this could be a problem on Unix or MacOS, causing ThinLTO reader to read “incorrect” cache file.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D">Problem 4(c): 1<sup>st</sup> process starts reading the cache file with the name “llvmcache-foo” block by block, while the writer from the 2<sup>nd</sup> process
renames the temp file into “llvmcache-foo”. Are you encountering this? <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D">Again, I don’t think this is a real problem on Windows as long as FILE_SHARE_DELETE flag is supported (might not be true for some Windows file systems) and both
processes open cache file with FILE_SHARE_DELETE (true). It might be a problem on MacOS or Unix causing ThinLTO reader to read incorrect cache file.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D">If you are seeing one of these issues above, I suspect the straightforward solution that we talked about (Solution #0 in my original proposal) or leveraging Peter’s
new C++ LTO API won’t be sufficient (since both of them take care of the Problems #1,#2 and #3, but not about the Problem #4). In this case we might have to implement a “full-fledged” solution #1 or #2 (with read-write blocks).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D">Summary:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D">With the exception of some not-so-common file systems on Windows which do *<b>not</b>* support FILE_SHARE_DELETE flag, 4b and 4c should not cause problems on Windows.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D">If 4b and 4c are not causing issues for MacOS, they shouldn’t cause issues for any other FreeBSD-based OS (or any other Unix-type OS in general). Could you please
consult with MacOS VFS developers? <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D">If they reassure you that everything is fine, we will implement light-weighted solution #0 or leverage functionality from new C++ LTO API as proposed by Peter.
Otherwise, we will consider more heavy-weight solution #1, #2 or some other.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D"><o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-right:.5in"><span style="font-family:"Arial",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">For its current design, you cannot shared the LTO cache between two linking. For example, if you are building llc and libLTO from LLVM and they shared many same static archives with common LTO object files, you still need to use two different
LTO caches. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D">But what if we fix this particular problem? We could either do it the way Peter implemented it for the new LTO API or the way we discussed above. I assume that
after fixing this, will we be able to share the same cache between 2 links.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D">The question is, how exactly we should fix it for C LTO API? I’m aware of only two major C LTO API stakeholders (Apple and Sony), so most likely nobody else cares
much about legacy C API. Peter generously proposed to port the non-racy algorithm from new LTO API to the legacy C API. I looked into new LTO API today and it looks that the data race is fixed there, though the code is more heavy C++ and will be harder to
read. Alternatively, I could write a simpler patch for legacy C LTO API, doing what we discussed above (i.e. creating temp files in cache directory and if renaming of the temp into a cache file failed, bypass reading from the cache file).</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Arial",sans-serif;color:#1F497D">What do you think?</span><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I haven't read the C++ API implementation but I am all up to improve C LTO API to allow sharing. If nothing else, we can get faster ThinLTO build time for LLVM.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Steven<o:p></o:p></p>
</div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal">Steven<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New""> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">Thank you!</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"Courier New"">Katya.</span><o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>