Make ADOL-C thread-save

[chrhansk]

This is in response to #35 . My idea would be to make the current tape information thread_local and add synchronization based on standard C++ constructs, so there are no other libraries required.

The key difference is that the OpenMP parallel functions are executed within ADOL-C itslef, whereas I would like to execute ADOL-C from several different threads created elsewhere...

This is not yet finished, there still seem to be some issues when running ADOL-C in parallel code...

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

Christoph Hansknecht seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[mflehmig]

Hi @chrhansk,

can you please provide kind of a minimal example serving as use case?

Best regards
Martin

[chrhansk]

@mflehmig: I added a test case which hopefully demonstrates the desired functionality. It does not work yet, there are apparently still some race conditions in the code.

[vryy]

@chrhansk Thanks for the work. This is a very desired functionality. Do you have any update on that?

[chrhansk]

@vryy: Admittedly, I lost interest a bit over the last years. I was interested in the functionality for multiple shooting approaches for ODEs, which of course permit parallelization easily enough.

The problem is nontrivial due to the number of global variables used by ADOL-C. Every trace_on() / trace_off() manipulates these variables, which has to be synchronized.

If you run the parallel test with thread sanitizing enabled, you will see a lot of data races (and encounter sagfaults), so at the very least, all of those would need to be fixed. I think some issues are present in fo_rev.c, which is heavily #defined and a little difficult to read.

I think that the changes will be hard to make without anyone who knows the code well. So far however, this issues does not seem to have raised much interest so far. Do you need the functionality for a project yourself?

[awalther1]

Hi,

currently nobody from the ADOL-C developer team works in the area of parallelization. Therefore, for us it is difficult to support improvements in this direction.

I am sorry for that but happy to support anybody working in this direction!

Best regards

Andrea

[vryy]

@vryy: Admittedly, I lost interest a bit over the last years. I was interested in the functionality for multiple shooting approaches for ODEs, which of course permit parallelization easily enough.

The problem is nontrivial due to the number of global variables used by ADOL-C. Every trace_on() / trace_off() manipulates these variables, which has to be synchronized.

If you run the parallel test with thread sanitizing enabled, you will see a lot of data races (and encounter sagfaults), so at the very least, all of those would need to be fixed. I think some issues are present in fo_rev.c, which is heavily #defined and a little difficult to read.

I think that the changes will be hard to make without anyone who knows the code well. So far however, this issues does not seem to have raised much interest so far. Do you need the functionality for a project yourself?

The code I'm working on performs element assembly & solve in parallel hence setting the thread to 1 slows everything down. I work around it by setting the number of threads for the solver in the code. Still, the assembly is pretty slow. Therefore, it would be nice to have this feature.

[DwyaneTalk]

nice work!
I have the same problem, this change will be merged or some other test is needed?

[chrhansk]

Well, to reiterate, this was some initial draft. It does not work correctly.

[cgraeser]

I ran into this, too, when trying to use ADOL-C with c++ std::thread in thread parallel FEM assembly.

As a first step it would be nice if one could at least evaluate functions/derivatives in parallel from a tape that has been recorded sequentially before. Unfortunately, this still fails for me with a segfault, although I would guess that this should conceptually not manipulate global/shared state.