dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

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.

Garth


> Johan
>
> > > Is it possible to have a pool of Data objects and have each thread
> > >
> > > select the proper one:
> > >     data[thread_id]
> >
> > That's messy because the Data object is buried deep in the code.
> >
> > I think that we should avoid this design (private scratch space) and try
> > to figure out an alternative. I removed the private scratch from
> > Function the other day.
>
>
> > > --
> > > Anders
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~dolfin
> > Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~dolfin
> > More help   : https://help.launchpad.net/ListHelp