![\"DealingWithMutation\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2023\/05\/DealingWithMutation.png\")
<\/p>\nI continue my journey with concurrency patterns in today’s post. The Thread-Safe Interface fits very well when the critical sections are just objects.<\/p>\n
<\/p>\n
<\/p>\n
The naive idea to protect all member functions of a class with a lock causes, in the best case, a performance issue and, in the worst case, a deadlock.<\/p>\n
The small code snippet has a deadlock.<\/p>\n
<\/p>\n
struct<\/span> Critical{\r\n void<\/span> memberFunction1(){\r\n lock(mut);\r\n memberFunction2();\r\n ...\r\n}\r\n\r\nvoid<\/span> memberFunction2(){\r\n lock(mut);\r\n ...\r\n }\r\n\r\n mutex mut;\r\n};\r\n\r\nCritical crit;\r\ncrit.memberFunction1();\r\n<\/pre>\n<\/div>\n <\/p>\n
Calling crit.memberFunction1<\/code> causes the mutex mut<\/code> to be locked twice. For simplicity reasons, the lock is a scoped lock. Here are the two issues:<\/p>\n\n- When
lock<\/code> is a recursive lock, the second lock(mut)<\/code> in memberFunction2<\/code> is redundant.<\/li>\n- When
lock<\/code> is a non-recursive lock, the second lock(mut)<\/code> in memberFunction2<\/code> leads to undefined behavior. Most of the time, you get a deadlock.<\/li>\n<\/ul>\nThe thread-safe interface overcomes both issues.<\/p>\n
The Thread-Safe Interface<\/h2>\n
Here is the straightforward idea of the Thread-Safe Interface.<\/p>\n
\n- All interface member functions (
public<\/code>) use a lock.<\/li>\n- All implementation member functions (
protected<\/code> and private<\/code>) must not use a lock.<\/li>\n- The interface member functions call only protected or private member functions but no public member functions.<\/li>\n<\/ul>\n
The following program shows the usage of the Thread-Safe Interface.<\/p>\n
<\/p>\n
\n\/\/ threadSafeInterface.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n#include <mutex><\/span>\r\n#include <thread><\/span>\r\n\r\nclass<\/span> Critical<\/span>{\r\n\r\npublic:<\/span>\r\n void<\/span> interface1() const<\/span> {\r\n std::<\/span>lock_guard<<\/span>std::<\/span>mutex><\/span> lockGuard(mut);\r\n implementation1();\r\n }\r\n \r\n void<\/span> interface2(){\r\n std::<\/span>lock_guard<<\/span>std::<\/span>mutex><\/span> lockGuard(mut);\r\n implementation2();\r\n implementation3();\r\n implementation1();\r\n }\r\n \r\nprivate:<\/span> \r\n void<\/span> implementation1() const<\/span> {\r\n std::<\/span>cout <<<\/span> \"implementation1: \"<\/span> \r\n <<<\/span> std::<\/span>this_thread::<\/span>get_id() <<<\/span> '\\n'<\/span>;\r\n }\r\n void<\/span> implementation2(){\r\n std::<\/span>cout <<<\/span> \" implementation2: \"<\/span> \r\n <<<\/span> std::<\/span>this_thread::<\/span>get_id() <<<\/span> '\\n'<\/span>;\r\n }\r\n void<\/span> implementation3(){ \r\n std::<\/span>cout <<<\/span> \" implementation3: \"<\/span> \r\n <<<\/span> std::<\/span>this_thread::<\/span>get_id() <<<\/span> '\\n'<\/span>;\r\n }\r\n \r\n\r\n mutable<\/span> std::<\/span>mutex mut; \/\/ (1)\r\n<\/span><\/em>\r\n};\r\n\r\nint<\/span> main<\/span>(){\r\n \r\n std::<\/span>cout <<<\/span> '\\n'<\/span>;\r\n \r\n std::<\/span>thread<\/span> t1([]{ \r\n const<\/span> Critical crit;\r\n crit.interface1();\r\n });\r\n \r\n std::<\/span>thread<\/span> t2([]{\r\n Critical crit;\r\n crit.interface2();\r\n crit.interface1();\r\n });\r\n \r\n Critical crit;\r\n crit.interface1();\r\n crit.interface2();\r\n \r\n t1.join();\r\n t2.join(); \r\n \r\n std::<\/span>cout <<<\/span> '\\n'<\/span>;\r\n \r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
Three threads, including the main thread, use instances of Critical<\/code>. Thanks to the Thread-Safe Interface, all calls to the public API are synchronized. The mutex mut<\/code> in line (1) is mutable and can be used in the constant member function interface1<\/code>.<\/p>\nThe advantages of the thread-safe interface are threefold.<\/p>\n
\n- A recursive call of a mutex is not possible. Recursive calls on a non-recursive mutex are undefined behavior in C++ and usually end in a deadlock.<\/li>\n
- The program uses minimal locking and, therefore, minimal synchronization. Using just a
std::recursive_mutex<\/code> in each member function of the class Critical<\/code> would end in more expensive synchronization.<\/li>\n- From the user’s perspective,
Critical<\/code> is straightforward to use because synchronization is only an implementation detail.<\/li>\n<\/ol>\n <\/p>\n
Each interface member function delegates its work to the corresponding implementation member function. The indirection overhead is a typical disadvantage of the Thread-Safe Interface.<\/p>\n
The output of the program shows the interleaving of the three threads.<\/p>\n
![\"threadSafeInterface\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2023\/05\/threadSafeInterface.png\")
<\/p>\n
Although the Thread-Safe Interface seems easy to implement, there are two grave perils you have to keep in mind.<\/p>\n<\/p>\n
Perils<\/h3>\n
Using a static member in your class or having virtual interfaces requires special care.<\/p>\n
Static members<\/h4>\n
When your class has a static member that is not constant, you must synchronize all member function calls on the class instances.<\/p>\n
<\/p>\n
\nclass<\/span> Critical<\/span>{\r\n \r\npublic:<\/span>\r\n void<\/span> interface1() const<\/span> {\r\n std::<\/span>lock_guard<<\/span>std::<\/span>mutex><\/span> lockGuard(mut);\r\n implementation1();\r\n }\r\n void<\/span> interface2(){\r\n std::<\/span>lock_guard<<\/span>std::<\/span>mutex><\/span> lockGuard(mut);\r\n implementation2();\r\n implementation3();\r\n implementation1();\r\n }\r\n \r\nprivate:<\/span> \r\n void<\/span> implementation1() const<\/span> {\r\n std::<\/span>cout <<<\/span> \"implementation1: \"<\/span> \r\n <<<\/span> std::<\/span>this_thread::<\/span>get_id() <<<\/span> '\\n'<\/span>;\r\n ++<\/span>called;\r\n }\r\n void<\/span> implementation2(){\r\n std::<\/span>cout <<<\/span> \" implementation2: \"<\/span> \r\n <<<\/span> std::<\/span>this_thread::<\/span>get_id() <<<\/span> '\\n'<\/span>;\r\n ++<\/span>called;\r\n }\r\n void<\/span> implementation3(){ \r\n std::<\/span>cout <<<\/span> \" implementation3: \"<\/span> \r\n <<<\/span> std::<\/span>this_thread::<\/span>get_id() <<<\/span> '\\n'<\/span>;\r\n ++<\/span>called;\r\n }\r\n \r\n inline<\/span> static<\/span> int<\/span> called{0<\/span>}; \/\/ (1)<\/span><\/em>\r\n inline<\/span> static<\/span> std::<\/span>mutex mut;\r\n\r\n};\r\n<\/pre>\n<\/div>\n <\/p>\n
Now, the class Critical<\/code> has a static member called<\/code> (line 32) to count how often the implementation functions were called. All instances of Critical<\/code> use the same static member and have, therefore, to be synchronized. Since C++17, static data members can be declared inline. An inline static data member can be defined and initialized in the class definition.<\/p>\nVirtuality<\/h4>\n
When you override a virtual interface function, the overriding function should have a lock even if the function is private.<\/p>\n
<\/p>\n
\n\/\/ threadSafeInterfaceVirtual.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n#include <mutex><\/span>\r\n#include <thread><\/span>\r\n\r\nclass<\/span> Base<\/span>{\r\n \r\npublic:<\/span>\r\n virtual<\/span> void<\/span> interface() {\r\n std::<\/span>lock_guard<<\/span>std::<\/span>mutex><\/span> lockGuard(mut);\r\n std::<\/span>cout <<<\/span> \"Base with lock\"<\/span> <<<\/span> '\\n'<\/span>;\r\n }\r\n virtual<\/span> ~<\/span>Base() =<\/span> default<\/span>;\r\nprivate:<\/span>\r\n std::<\/span>mutex mut;\r\n};\r\n\r\nclass<\/span> Derived<\/span>:<\/span> public<\/span> Base{\r\n\r\n void<\/span> interface() override {\r\n std::<\/span>cout <<<\/span> \"Derived without lock\"<\/span> <<<\/span> '\\n'<\/span>;\r\n }\r\n\r\n};\r\n\r\nint<\/span> main<\/span>(){\r\n\r\n std::<\/span>cout <<<\/span> '\\n'<\/span>;\r\n\r\n Base*<\/span> base1 =<\/span> new<\/span> Derived;\r\n base1-><\/span>interface();\r\n\r\n Derived der;\r\n Base&<\/span> base2 =<\/span> der;\r\n base2.interface();\r\n\r\n std::<\/span>cout <<<\/span> '\\n'<\/span>;\r\n\r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
In the calls, base1->interface<\/code> and base2.interface<\/code> the static type of base1<\/code> and base2<\/code> is Base,<\/code> and, therefore, the interface<\/code> is accessible. Because the interface member function is virtual, the call happens at run time using the dynamic type Derived<\/code>. At last, the private member function interface<\/code> of the class Derived<\/code> is invoked.<\/p>\nThe program’s output shows the unsynchronized invocation of Derived’s interface function.<\/p>\n
![\"threadSafeInterfaceVirtual\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2023\/05\/threadSafeInterfaceVirtual.png\")
<\/p>\n
There are two typical ways to overcome this issue.<\/p>\n
\n- Make the member function interface a non-virtual member function. This technique is called NVI (Non-Virtual Interface). The non-virtual member function guarantees that the interface function of the base class
Base<\/code> is used. Additionally, overriding the interface function using override<\/code> causes a compile-time error because there is nothing to override.<\/li>\n- Declare the member function interface as
final<\/code>: virtual void interface() final<\/code>. Thanks to final<\/code>, overriding an as final<\/code> declared virtual member function causes a compile-time error.<\/li>\n<\/ol>\n