You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by da...@dotech.com on 2004/07/28 23:04:28 UTC
mutex tasks
I'm just curious about how usefull other folks would find this.
I've created 2 tasks <Wait> and <Notify>.
The use case is where you have parallel ants running (on some server) doing
builds, but 1 part of the build (in our case, some JFCUnit) needs to be single
threaded. By this I mean that each of the build/validates that we are doing can
run in parallel, with the exception of the JFCUnit portion due to focus
issues.
So, wrap the JFCUnit portion of the validate in the <Wait> <Notify> tasks. What
wait does is create a lock file, check for other locks, of none exist, it goes
forward. If other locks exist, it removes its lock file and does a random wait
(based on parameters) and tries again. <Notify> simply removes the lock.
I have a test build file and the working tasks if anyone wants to see and play
around.
David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: mutex tasks
Posted by da...@dotech.com.
I removed the race condition by having each parallel ant process using a unique
name. That is really up to the build file, but that is the way it was designed.
So, there shouldn't be any race condition. If 2 files get created at the same
time, each <wait> task will remove their own file and do a random backoff
before trying again.
David
Quoting Phil Weighill-Smith <ph...@volantis.com>:
> David,
>
> You're far better (from the atomicity and portability points-of-view)
> creating a directory instead of a file - directories can't be re-created
> on any filesystem I've used while files can be (so you might think you
> created the lock file but didn't due to a race condition).
>
> Phil :n.
>
> On Thu, 2004-07-29 at 13:11, dak@dotech.com wrote:
>
> > I've just dome some testing in XP. The locks are simply zero length files
> and
> > nothing more. Also, because of the random backoff approach, I think it
> would be
> > pretty robust. To clean up any locks left over from previous attempts, a
> > mastster scheduler could simply remove all files in the locks directory.
> Should
> > I post code, and a build file example? I could also submit a patch to
> bugzilla
> > with all the stuff attached.
> >
> > David
> >
> > Quoting Steve Loughran <st...@apache.org>:
> >
> > >
> > > This is interesting. File locks worry me as they can be quirky on
> > > platforms and across shared file systems. And on winnt workstation,
> > > locks never seem to get released when an app crashes (unlike winnt
> server).
> > >
> > > What have you tested on?
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail: dev-help@ant.apache.org
>
> --
> Phil Weighill-Smith <ph...@volantis.com>
> Volantis Systems
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> Questions, Problems or Concerns contact messagelabs-admin@dotech.com.
> ______________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: mutex tasks
Posted by Phil Weighill-Smith <ph...@volantis.com>.
David,
You're far better (from the atomicity and portability points-of-view)
creating a directory instead of a file - directories can't be re-created
on any filesystem I've used while files can be (so you might think you
created the lock file but didn't due to a race condition).
Phil :n.
On Thu, 2004-07-29 at 13:11, dak@dotech.com wrote:
> I've just dome some testing in XP. The locks are simply zero length files and
> nothing more. Also, because of the random backoff approach, I think it would be
> pretty robust. To clean up any locks left over from previous attempts, a
> mastster scheduler could simply remove all files in the locks directory. Should
> I post code, and a build file example? I could also submit a patch to bugzilla
> with all the stuff attached.
>
> David
>
> Quoting Steve Loughran <st...@apache.org>:
>
> >
> > This is interesting. File locks worry me as they can be quirky on
> > platforms and across shared file systems. And on winnt workstation,
> > locks never seem to get released when an app crashes (unlike winnt server).
> >
> > What have you tested on?
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
--
Phil Weighill-Smith <ph...@volantis.com>
Volantis Systems
Re: mutex tasks
Posted by da...@dotech.com.
I've just dome some testing in XP. The locks are simply zero length files and
nothing more. Also, because of the random backoff approach, I think it would be
pretty robust. To clean up any locks left over from previous attempts, a
mastster scheduler could simply remove all files in the locks directory. Should
I post code, and a build file example? I could also submit a patch to bugzilla
with all the stuff attached.
David
Quoting Steve Loughran <st...@apache.org>:
>
> This is interesting. File locks worry me as they can be quirky on
> platforms and across shared file systems. And on winnt workstation,
> locks never seem to get released when an app crashes (unlike winnt server).
>
> What have you tested on?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: mutex tasks
Posted by Steve Loughran <st...@apache.org>.
dak@dotech.com wrote:
> I'm just curious about how usefull other folks would find this.
>
> I've created 2 tasks <Wait> and <Notify>.
> The use case is where you have parallel ants running (on some server) doing
> builds, but 1 part of the build (in our case, some JFCUnit) needs to be single
> threaded. By this I mean that each of the build/validates that we are doing can
> run in parallel, with the exception of the JFCUnit portion due to focus
> issues.
>
> So, wrap the JFCUnit portion of the validate in the <Wait> <Notify> tasks. What
> wait does is create a lock file, check for other locks, of none exist, it goes
> forward. If other locks exist, it removes its lock file and does a random wait
> (based on parameters) and tries again. <Notify> simply removes the lock.
>
> I have a test build file and the working tasks if anyone wants to see and play
> around.
This is interesting. File locks worry me as they can be quirky on
platforms and across shared file systems. And on winnt workstation,
locks never seem to get released when an app crashes (unlike winnt server).
What have you tested on?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org