← Back to team overview

dolfin team mailing list archive

Re: Data in GenericFunction

 



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.

Garth

--
Anders



Follow ups

References