for review: bug fix for concurrent writes to `.d' files

Tyson Dowd trd at stimpy.cs.mu.oz.au
Sat Feb 28 12:47:19 AEDT 1998


On 28-Feb-1998, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> On 27-Feb-1998, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > 	The fix is to write the dependency file to `<foo>.d.tmp' and
> > 	then rename the `.d.tmp' to `.d'.  This ensures that the update
> > 	to the `.d' file is atomic. 
> 
> Well, gee, now we have a concurrent write problem for
> the `.d.tmp' files.  Doh!
> 
> Obviously we need to use io__tepnam.  Let me try that again. 
> 
> [Testing this revised change revealed bugs in io__tmpnam;
> I'll commit the fixes for those as a separate change.]
> 
> --------------------
> 
> Estimated hours taken: 1
> 
> compiler/modules.m:
> 	Fix a bug with parallel makes where the `.d' files were being
> 	stuffed up because two different invocations of the Mercury
> 	compiler were writing to them at the same time. 
> 	The problem occurs because the `.d' file is written out
> 	both when creating the `.c' file and when creating the
> 	`.trans_opt' file, and these steps might happen in parallel.
> 
> 	The fix is to write the dependency file to a unique temporary
> 	file name and then rename it to the desired `.d' file name when
> 	we're done.  This ensures that the update to the `.d' file is atomic. 
> 	[In theory this is not a 100% portable solution, because
> 	rename() might not be atomic, but in practice it should be
> 	fine, because rename() is atomic on all the platforms of
> 	interest (i.e. all the ones that support parallel GNU make).]
> 
> 	An alternative fix would be to not write out the `.d' files
> 	when creating `.trans_opt' files.  This would also be more
> 	efficient.  However, the danger is that the `.d' files might
> 	not be updated often enough.  I'm not really sure exactly
> 	how often they need to be updated, but the fix using
> 	renaming seems safer.
>

This change seems fine (now).




More information about the developers mailing list