dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

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.

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