rjhogan / Adept-2

Combined array and automatic differentiation library in C++
http://www.met.reading.ac.uk/clouds/adept/
Apache License 2.0
163 stars 29 forks source link

Using Adept-2 in concurrent function calls #17

Closed kailaix closed 4 years ago

kailaix commented 4 years ago

Hello,

I was trying to use Adept-2 in a concurrency environment, where I defined a function as follows

void func(){
Stack stack;
...
}

The function func may be called concurrently. The program gave me segfault and the error appears to be related to conflicts of multiple active stacks. Currently, I have a workaround by using a mutex and the error disappears.

std::mutex mu; 
void func(){
const std::lock_guard<std::mutex> lock(mu);
Stack stack;
}

But this can degrade performance, especially when func is very expensive. What is the optimal way in Adept-2 to handle this issue? Thanks!

BTW, thanks for developing Adept-2. The AD and array functionalities are really useful, and the syntax is pretty intuitive and elegant. 👍

rjhogan commented 4 years ago

Could you tell me your compiler and platform? "Stack" should be thread safe because it uses thread-local storage for the global pointer to the Stack object. However, when I wrote this bit, thread-local storage was not available on Mac C++ so I disabled it. If you are using a Mac this could be the reason. Perhaps the C++11 compilers have improved on the Mac, in which case you could try compiling with -DADEPT_THREAD_LOCAL=thread_local plus whatever option you use on your compiler to use conform to the C++11 standard. This will then use the C++11 keyword "thread_local", regardless of your platform. You can also hack the include file include/adept/base.h to set ADEPT_THREAD_LOCAL.

kailaix commented 4 years ago

Thank you for your reply. I use Mac and my OS version is 10.15.3. Here is the compiler information

➜  ~ g++ --version
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 11.0.0 (clang-1100.0.33.17)
Target: x86_64-apple-darwin19.3.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
➜  ~ gcc --version
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 11.0.0 (clang-1100.0.33.17)
Target: x86_64-apple-darwin19.3.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

I'll try your suggestion.

rjhogan commented 4 years ago

@kailaix Did it work?

kailaix commented 4 years ago

I could not find the original broken code. But now I modify all my codes using your strategy, and they work smoothly. Thanks a lot.

rjhogan commented 4 years ago

OK thanks. The latest push has added a preprocessor test to base.h that ought to detect whether the Clang compiler on Mac OS supports thread_local. So then you wouldn't need to use -DADEPT_THREAD_LOCAL. If you have time it would be useful if you could test this, but for the moment I'll close the issue and only reopen it if the new push doesn't work as intended.