dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Monday 05 October 2009 11:51:19 Garth N. Wells wrote:
> Johan Hake wrote:
> > On Monday 05 October 2009 11:35:09 Garth N. Wells wrote:
> >> Johan Hake wrote:
> >>> On Monday 05 October 2009 11:21:34 Anders Logg wrote:
> >>>> On Mon, Oct 05, 2009 at 09:33:48AM +0200, Johan Hake wrote:
> >>>>> Hello!
> >>>>>
> >>>>> The one reason (as I can recall) to include the Data class, for
> >>>>> passing of information to the former Function::eval method, was for
> >>>>> future thread safety.
> >>>>
> >>>> I don't remember but that may be one of the reasons. There were
> >>>> others.
> >>>
> >>> Ok.
> >>>
> >>>>> Previously we stored the Cell, and some other stuff, as a public
> >>>>> accessible member, before we called eval during assemble. This was
> >>>>> not thread safe.
> >>
> >> It can be made thread-safe if Data has a copy constructor. I played with
> >>   parallelising the assembly loop using OpenMP, and to do that I needed
> >> to add a copy constructor to UFC since each thread needed its own UFC
> >> object.
> >
> > Ok, but too much copying does not sound efficient?
> 
> It's done outside a loop that is parallelised. Copying the Function
> would only involve Function copies that all point to the same data, with
> the exception of the Data object, which they would need their own copy of.

Ok.

Johan

> Garth
> 
> > Johan
> >
> >> Garth
> >>
> >> Instead we agreed on passing this data as argument, making
> >>
> >>>>> it more thread safe.
> >>>>>
> >>>>> This might not be a big issue if we, when we implement support for
> >>>>> threads (whenever this happens...) let the local Data object be
> >>>>> stored in an indexed std::vector, and then keep the present eval
> >>>>> interface.
> >>>>
> >>>> Sounds like it could work, but we'll see when get to that point. It
> >>>> doesn't matter for the current parallel implementation.
> >>>
> >>> Ok.
> >>>
> >>> Johan
> >>> _______________________________________________
> >>> DOLFIN-dev mailing list
> >>> DOLFIN-dev@xxxxxxxxxx
> >>> http://www.fenics.org/mailman/listinfo/dolfin-dev
>