← Back to team overview

dolfin team mailing list archive

Re: Function design / Future multicore support in DOLFIN

 

On Sun, Nov 02, 2008 at 03:52:17PM +0000, Garth N. Wells wrote:
> 
> 
> Joachim B Haga wrote:
> > "Martin Sandve Alnæs" <martinal@xxxxxxxxx> writes:
> > 
> >> 2008/11/2 Joachim B Haga <jobh@xxxxxxxxxxxx>:
> >>>>> On Saturday 01 November 2008 17:10:09 Martin Sandve Alnæs wrote:
> >>>>>> 2008/11/1 Garth N. Wells <gnw20@xxxxxxxxx>:
> >>>>>>> So if we remove
> >>>>>>>
> >>>>>>>  mutable Cell* _cell
> >>>>>>>  mutable int _facet
> >>>>>>>
> >>>>>>> from the private member data of Function, does this resolve the
> >>>>>>> biggest design issue for running multi-threaded?
> >>>>>> Yes. Otherwise the threads will overwrite each others current cell all
> >>>>>> the time.
> >>> If you can get away with making these variables static, thread-local
> >>> variables (storage class __thread) is simpler.
> >>
> >> But static... That sounds very limiting.
> > 
> > Perhaps. In that case, I'd suggest just letting each thread have its own
> > instance of any mutable classes, if that's possible.
> >
> 
> Isn't Martin's suggestion that the necessary data be passed to the eval 
> function much simpler?
> 
> Garth

Yes, the implementation would be much simpler, but it would be
inconvenient if all user-defined functions must be defined with all the
arguments:

  void eval(double* values, double* x, const Cell& cell, uint facet, ...)

We could introduce a new class Data (or similar) that contains x and
possibly a lot of other stuff:

  void eval(double* values, const Data& data)
  {
    values[0] = sin(data.x[0]);
  }

The data variable can have member functions cell(), facet() etc.

-- 
Anders

Attachment: signature.asc
Description: Digital signature


Follow ups

References