dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #10516
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