dolfin team mailing list archive

[Joachim B Haga <jobh@xxxxxxxxxxxx>]

Anders Logg <logg@xxxxxxxxx> writes:

> On Sat, Nov 01, 2008 at 07:08:14PM +0100, Johan Hake wrote:
>> On Saturday 01 November 2008 17:10:09 Martin Sandve Alnæs wrote:
>> > 2008/11/1 Garth N. Wells <gnw20@xxxxxxxxx>:
>> > > So if we remove
>> > >
>> > >  mutable Cell* _cell
>> > >  mutable int _facet
>> > >
>> > > from the private member data of Function, does this resolve the biggest
>> > > design issue for running multi-threaded?
>> >
>> > Yes. Otherwise the threads will overwrite each others current cell all the
>> > time.
>> 
>> Would it be possible to store the present Cell* and facet in two vectors of
>> length #threads. Then we either have to call the cell(), facet() and
>> normal() with the present thread number or if it is possible to implement a
>> static function that returns the present thread number in these
>> functions. If the last option is not possible we need to call the eval
>> function with the present thread number.
>
> This is what I've been planning (but I don't know how to implement it).
>
> If we can get the thread number, it should be simple. User-defined
> functions access the cell and facet by the functions cell() and
> facet(), so those functions may just pick the data from an array.

Be careful so you don't introduce cache-line sharing, otherwise performance
will suffer. A simple array of ints (for example) is no-no, the data for
different processors should be spaced by the cache-line size. Padding to 128
bytes will probably cover most processors.

If you can get away with making these variables static, thread-local variables
(storage class __thread) is simpler. Maybe not completely portable though...

-j.