Martin
Den 1. des. 2010 12.29 skrev "Garth N. Wells" <gnw20@xxxxxxxxx
<mailto:gnw20@xxxxxxxxx>> 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 : dolfin@xxxxxxxxxxxxxxxxxxx <mailto:dolfin@xxxxxxxxxxxxxxxxxxx>
> Unsubscribe : https://launchpad.net/~dolfin
> More help : https://help.launchpad.net/ListHelp
