-
Notifications
You must be signed in to change notification settings - Fork 26
Add C++ binding/implementation thread safety options #220
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: develop
Are you sure you want to change the base?
Conversation
b1df7c1
to
53405b6
Compare
…ticComponentToolkit into uck/ThreadSafety
53405b6
to
cba7f69
Compare
…ticComponentToolkit into uck/ThreadSafety
int main() | ||
{ | ||
std::string libpath = (""); // TODO: put the location of the LibThreadSafe-library file here. | ||
auto wrapper = LibThreadSafe::CWrapper::loadLibrary(libpath + ""); // TODO: add correct suffix of the library |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
library is not mentioned here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good. thank you. left few comments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could build the example and run it. It creates the class instances. Thank you. I will add this to the build pipeline later.
This solution adds 2 new virtual methods IBase::_lockInstance and IBase::_UnlockInstance on the implementation side with empty implementation. It also adds new class IBaseWithMutex that derives from Ibase. Those methods are being injected to base class methods so they will be exposed through and API (as private). It all happens only if one (or more) class has ThreadSafetyOption attribute set to "strict" or "soft".
Difference between soft and strict:
soft - binding side will call _lockInstance only if string / array is returned from API function
strict - binding side will call _lockInstance everytime, no matter what is returned from function
IBaseWithMutex Definition:
When ThreadSafetyOption attribute in LibraryManager component class is set to "soft" or "strict", ILibraryManager will derive from IBaseWithMutex instead of Ibase
Example binding side functions created when ThreadSafetyOption is set to soft:
With this approach we are locking / unlocking mutex on implementation side so we can have X different instances of the Binding-Class pointing to the same Implementations-Class and all of this should work fine. On the binding side _lockInstance and _unlockInstance are private so one should use them by accident.
One more thing, CheckError will unlock hande in case of "exception propagation"
Just like with binding side, any changes on binding side will happen only when one (or more) class has ThreadSafetyOption attribute set to "strict" or "soft".