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@fenics.org > >>> http://www.fenics.org/mailman/listinfo/dolfin-dev > _______________________________________________ DOLFIN-dev mailing list DOLFIN-dev@fenics.org http://www.fenics.org/mailman/listinfo/dolfin-dev
