search

coin-or / qpOASES

Open-source C++ implementation of the recently proposed online active set strategy
GNU Lesser General Public License v2.1
376 stars 127 forks source link

QProblem reentrancy #35

Open svigerske opened 4 years ago

svigerske commented 4 years ago

Issue created by migration from Trac.

Original creator: dbulgakov

Original creation time: 2015-03-19 17:58:56

Assignee: ferreau

Version: 3.0.1

Currently usage of separate instances of QProblem in different threads is not safe because it uses global shared message handler. When a few threads solve separate problems incorrect behavior related to messages output is observed. It would be good to protect message handler.

svigerske commented 4 years ago

Comment by ferreau created at 2015-03-20 07:16:21

This is a valid suggestion and I fully agree that we should fix this in the near future.

Can you tell us what kind of incorrect behaviour you have observed? The globalMessageHandler has only very few member variables; so assuming one keeps the output settings the same for all QP instances, the main misbehaviour might be "only" wrong identation of error messages (based on count). In any case, we should fix this thoroughly.

svigerske commented 4 years ago

Comment by ferreau created at 2015-03-20 07:16:21

Changing status from new to assigned.

svigerske commented 4 years ago

Comment by dbulgakov created at 2015-03-20 14:24:00

Even if you disable message output for each problem (via options) multiple incomplete messages still come to output.

svigerske commented 4 years ago

Comment by ferreau created at 2015-03-23 13:05:51

I basically see two ways to work around this issue:

1) Add syncronization primitives around the use of the globalMessageHandler, though I suspect this to reduce portability of the code.

2) Have a "localMessageHandler" either for each instance of each class or one per (S)QProblem(B) instance and make it accessible by all members. Drawbacks are additional memory overhead (though small) and that the devil will be in the details (e.g. the utility functions do not belong to any object but also may throw messages).

What is your take on that?