Or add it to ufc::cell?
Martin Den 1. des. 2010 12.29 skrev "Garth N. Wells" <[email protected]> følgende: > > > 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) > > ? > > Garth > >> -- >> Anders > > > _______________________________________________ > Mailing list: https://launchpad.net/~dolfin > Post to : [email protected] > Unsubscribe : https://launchpad.net/~dolfin > More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
