KratosMultiphysics / Kratos

Kratos Multiphysics (A.K.A Kratos) is a framework for building parallel multi-disciplinary simulation software. Modularity, extensibility and HPC are the main objectives. Kratos has BSD license and is written in C++ with extensive Python interface.
https://kratosmultiphysics.github.io/Kratos/
Other
1.01k stars 244 forks source link

Creating a shared object holding workspaces per thread #6021

Open thelfer opened 4 years ago

thelfer commented 4 years ago

In the case of the MGISApplication, i would like to have to create an object shared among all the clones of a constitutive law. This object will handle workspaces per thread to avoid memory allocations each tme the constitutive integration is called.

This issue discusses the best way to achieve this in Kratos.

My first idea is to use std::threadid to see if a workspace has been assigned to the current thread and allocate one if not. This step is proctected by a mutex.

loumalouomega commented 4 years ago

As it is a quite technical discussion I add @pooyan-dadvand and @RiccardoRossi to the discussion

loumalouomega commented 4 years ago

BTW, creating a class more efficient that Parameters to be shared as a variable stored in the Properties is not a possible option?

thelfer commented 4 years ago

@loumalouomega The main idea here is that each integration points requires a workspace that I would like to be allocated only once. The trouble is here multithreading as this workspace is mutable. Maybe I am wrong, but I don't expect Properties to handle multithreading issues (at least, I did not see anything in the source that would let me think that it does).

pooyan-dadvand commented 4 years ago

We used to have threadsafe globals in our elements but we had to remove them many years ago due to insufficient support of visual studio for OpenMP. (It used to not support the thread-safe statics) I should check again the compatibility for it. @RiccardoRossi do you have any update on it?

If we cannot go in that direction then we would make an object in the core to mimic that by ourselves.

oberbichler commented 4 years ago

thread_local works fine with MSVC (AFAIK since 2015). Maybe the implementation of tbb's enumerable_thread_specific could also be interesting

pooyan-dadvand commented 4 years ago

Thanks for the update, @oberbichler. Yes, it is not a bad idea to have one implemented which internally change if we want to use openmp or c++ parallelization.