dolfin team mailing list archive

["Martin Sandve Alnæs" <martinal@xxxxxxxxx>]

2008/11/2 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.

I believe C++09 has thread local variables standardized.

But static... That sounds very limiting.

--
Martin