ObjectWeb Consortium
Search ObjectWeb Mail Archive: 

Advanced Search - Powered by Google


Mail Archive Home | proactive List | April 2006 Index

<--  Date Index  --> <--  Thread Index  -->

Re: [proactive] problems with barrier


Hello Łukasz,

I think you're having this problem because the barriers are not triggered when they occur in the middle of a method, but instead, they are run at the end of the method. Look at this code:
  public void MyMethodWithBarrier () {
      foo();
      ProSPMD.barrier("barrier");
      bar();
 }
Well, in this case, the call to bar() will be made BEFORE the barrier is really triggered. In fact, the barriers only start blocking at the END of the method. If you use something like "this.asyncRefToSelf.moveBody()", it's ok, because this call is put on the request queue, and will be effectively run AFTER the end of the current method. But if, like in your case (in the sendValueToNeighbours method), you use logger.info, this call is made before the barrier is really run, even if logger.info occurs after the barrier call in the code. So, to enforce the barrier, you should make the barrier the last action of your method, or you can use this trick:
      foo();
       ProSPMD.barrier("barrier");
      this.asyncRefToSelf.bar();
I agree this behavior is peculiar. It is not (to my taste) properly described in the documentation; I'll try to modify the documentation to highlight this issue.

I need a simple total barrier

I would use the ProSPMD.barrier("barrier") like you did, but splitting my method in two parts. Suppose you method looks like this:
  public void MyMethodWithBarrier () {
       instr_1; ... instr_k;
       ProSPMD.barrier("barrier");
       instr_k+1; ... instr_n;
       }
I would change it to something like this:
  public void MyMethodWithBarrier () {
       instr_1; ... instr_k;
       ProSPMD.barrier("barrier");
       this.asyncRefToSelf.endOfBarrierMethod();
       }

  public void endOfBarrierMethod () {
       instr_k+1; ... instr_n;
       }

Now, if this doesn't solve your problem, feel free to send another email!
You also said you experienced runtime errors with Barriers. I'd be most happy if you could pinpoint the code which yields these errors, as I have witnessed these myself without ever finding what caused them.
Best regards

Igor

--
Igor Rosenberg
Research engineer, OASIS project, INRIA
http://www-sop.inria.fr/oasis/personnel/Igor.Rosenberg/


Łukasz Mikulski wrote:

Hi,

I'm student from Torun, Poland.
I'm using your concurrent library and have found some problems using
barrier from ProSPMD (which cause runtime errors). After some tests
with my own code I've changed one of your classes
(org.objectweb.proactive.examples.nbody.groupoospmd.Domain) and I
think it may not work how I supposed it would. After running changed
oospmd version of nbody without display I've found that some planets
computes new positions before other gives them needed data (despite
barrier).

I enclose my version of Domain class.

Fragment of examplary output:
...
(0) Compute movement. 47
(1) After the barrier in 45
(1) Compute movement. 46
(1) Before sending position in step 46
(1) Gets the barrier in 46
...

Planet 0 computes movement in step 47 before planet 1 computes
movement (and could send its position to 0) in step 46.

Please tell me, if I'm not correct and advise how to solve this
problem. I need a simple total barrier (and group barrier in future).

--
with regard
Lukasz Mikulski




<--  Date Index  --> <--  Thread Index  -->

Reply via email to:

Powered by MHonArc.

Copyright © 1999-2005, ObjectWeb Consortium | contact | webmaster.