2008/11/2 Joachim B Haga <[EMAIL PROTECTED]>: > Anders Logg <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>: >>> > > 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 _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
