On Wed, Dec 01, 2010 at 11:26:42AM +0000, Garth N. Wells wrote: > > > On 30/11/10 23:15, Anders Logg wrote: > >On Tue, Nov 30, 2010 at 11:12:18PM +0000, Garth N. Wells wrote: > >> > >> > >>On 30/11/10 23:09, Anders Logg wrote: > >>>On Tue, Nov 30, 2010 at 10:48:09PM +0000, Garth N. Wells wrote: > >>>> > >>>> > >>>>On 30/11/10 22:37, Johan Hake wrote: > >>>>>On Tuesday November 30 2010 14:30:18 Garth N. Wells wrote: > >>>>>>On 30/11/10 22:25, Anders Logg wrote: > >>>>>>>On Tue, Nov 30, 2010 at 10:20:52PM +0000, Garth N. Wells wrote: > >>>>>>>>We have a thread-safe problem in GenericFunction with the member > >>>>>>>>object > >>>>>>>> > >>>>>>>> mutable Data data; > >>>>>>>> > >>>>>>>>Any ideas on how to get rid of it? We really should pass data > >>>>>>>>through the function interfaces, but we're constrained in this case > >>>>>>>>by the UFC interface. > >>>>> > >>>>>This is ironical, as Data was introduced so we in the future (now > >>>>>present) > >>>>>could be thread safe... > >>>> > >>>>Really? I remember Martin always warning against such a design > >>>>because it's not thread-safe. > >>>> > >>>>>But I do not think GenericFunction was a ufc::function > >>>>>at that time. > >>>>> > >>>>>Is it time to introduce the notion of thread in the ufc interface? > >>>>> > >>>> > >>>>Not for this purpose. What would be helpful is a way to pass > >>>>user-defined data through the UFC interface. Perhaps more > >>>>importantly, we should avoid using 'mutable'. A 'const' object > >>>>should in principle be thread-safe, but using mutable clouds this. > >>> > >>>Another solution (in addition to making the mutable data thread safe) > >>>would be to extend the UFC interface with a void* optional argument > >>>that can be passed to evaluate. > >>> > >>>Even if we add that, I suspect there will be a performance penalty if > >>>we need to recreate the Data object each time in > >>>restrict_as_ufc_function. In addition to convenience, Data is cached > >>>between calls so it can be reused. > >>> > >> > >>I'm trying the re-creation now. A good compiler might optimise away > >>the overhead. > > > >Let's hope. > > > > It seems that the only thing that we're missing relative to before > is the local facet index. Everything else can be dealt with. Perhaps > this could be added to the UFC interface, i.e., > > ufc::function::evaluate(double* values, > const double* coordinates, > const cell& c) > > could become > > ufc::function::evaluate(double* values, > const double* coordinates, > const cell& c, > int local_facet_index) > > ?
That sounds good. And -1 would signal that there the facet index is not available. -- Anders _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
