dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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.

--
Anders