dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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.

--
Anders