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. _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
