Re: Inconsistent behaviour when building in parallel

[Eli Zaretskii]

 From: Dirk Heinrichs [EMAIL PROTECTED]
 Date: Sat, 20 Jan 2007 22:22:04 +0100
 
 So the left hand doesn't know what the right hand does?

??? Would you care to explain where do you see two hands that don't
know each what the other one does?

As far as I see from Paul's clear description is that Make does the
same thing in both situations.

What would you expect Make to do in each case?

  In the parallel case you can't tell exactly what will happen: it depends
  on your system; how busy it is, what order the various jobs are
  scheduled by the OS, how long the command takes to execute, etc.  It
  could work perfectly, or it could be run twice, or more times (if there
  are more than two targets).
 
 That's even worse.

Really? why?

I'm sure you are familiar with the notion of multi-tasking or
multi-threading, and know that independent parallel execution threads
are much less deterministic than sequential single-threaded ones.
While that is a fact of life, this is the first time I hear someone
say that it is such a bad thing.

Anyway, you can always use -j1 if you don't want parallelism.


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Inconsistent behaviour when building in parallel

[Paul Smith]

On Sat, 2007-01-20 at 22:22 +0100, Dirk Heinrichs wrote:

  In the parallel case, make does exactly the same thing EXCEPT that
  instead of waiting for the first command to complete it immediately
  checks the second target and, since the first command is not done yet
  and hasn't updated it, make sees that it's still out of date so it runs
  that rule again to update it.
 
 So the left hand doesn't know what the right hand does? I consider this a bad 
 thing.

I do too, and so does make: that's why you shouldn't do it.  After all,
make cannot know what the commands you give it will REALLY do, it can
only assume that they will do what you've told it they will do: namely,
update the target file.

However, in your makefile your commands don't just update the target
file that you told make they would, they also update some OTHER target
files that you didn't tell make about.  So, make doesn't expect the
commands to update those target files.

In this case, the two hands you refer to are your commands that you
wrote and added to your makefile, so you can hardly blame make for what
they may be doing behind each others' backs.

  In the parallel case you can't tell exactly what will happen: it depends
  on your system; how busy it is, what order the various jobs are
  scheduled by the OS, how long the command takes to execute, etc.  It
  could work perfectly, or it could be run twice, or more times (if there
  are more than two targets).
 
 That's even worse.

Perhaps, but as Eli points out this is a feature of the operating system
and is completely out of make's control.  When you run multiple commands
in parallel on a multitasking system, you cannot control the order in
which they are executed.  That's the entire point: if they always ran in
a fixed order then they wouldn't be parallelized, would they?

As Eli says, if you want serialized command execution it's trivial to
get from make: just don't enable parallel builds.

-- 
---
 Paul D. Smith [EMAIL PROTECTED]  Find some GNU make tips at:
 http://www.gnu.org  http://make.paulandlesley.org
 Please remain calm...I may be mad, but I am a professional. --Mad Scientist


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make